您认为哪些架构视角是整体软件设计的一部分？

Question

当有人使用术语XXX架构时，我倾向于畏缩。它经常表明我可能没有考虑过另一种建筑学科或观点。您正在考虑建筑的哪些观点，并且您是否有足够的资源来获取有关它们的信息？

我希望这可以帮助那些正在通过建筑行业工作的人。

• 生存能力
• 绩效管理
• 运营监控＆amp;管理
• 服务导向
• TOGAF定义了许多服务质量属性

很抱歉编辑，但你的答案是现场，我认为这个问题需要改进。

Answer 1

架构和架构决策主要是关于系统的“非功能”要求; pace RoadWarrier，但他提到的每件事都是建筑决策的结果，而不仅仅是独立的结果。 （证明：什么导致在任何这些领域中的特定选择？总是需要满足一些非功能性要求。）

考虑到这一点，这是一个两部分问题。首先，您需要确定哪些NFR很重要。优选地通过使用严格的方法以某种特殊性来陈述它们，例如，不要只说“高度可用”，说“系统必须可用（MTTF /（MTTF + MTTR））99.99％，最长的单次持续时间中断是4分钟。“

其次，您需要考虑哪些视图可以帮助您设计以满足这些要求并证明您的决策。根据您的要求的严格程度，这可能是从白板框图到正式模拟研究的任何内容。

在 business 域中，例如在通过Web界面提供的IT系统中，您可能需要：

• 可靠性（MMTF）
• 可用性（MTTF /（MTTF + MTTR））
• 可扩展性（系统必须能够在X小时内在72小时内增加10 pct容量）
• 容量（系统必须维持100万活跃用户）
• 吞吐量（系统必须每秒处理100个事务，σ= 2.5 tps）
• 响应时间（在测试负载下用户必须在≤2秒内收到整页）
• 安全性（此处的指标本身就是一篇文章的主题）

如果您要指定性能等特征，还应该描述工作负载，即用户数据的大小，Web请求的到达率等。

Answer 2

• 可测试性
• 可扩展性
• 容错
• 性能下降（优雅，希望）
• 可升级性（硬件和软件）

BTW这些都是我喜欢企业服务总线（ESB）的原因！

Answer 3

编辑：由于问题的重点已经改变，我编辑了我的答案如下。

架构和架构师是严重超载的术语。首先，您需要指定您是在谈论软件公司（软件是产品/服务）还是业务线公司（软件支持产品/服务）。

还有自上而下的架构视图（从组织角度来看很重要）与自下而上的视图（从项目需求角度来看很重要）。

在一家大型的业务线公司中，自上而下（组织）观点的架构通常是这样划分的：

• Domain架构，有时称为业务架构。例如，了解商品交易流程和相关的IT系统。
• Data架构。例如，理解存储中的数据和运动中的数据的描述;数据存储，数据组和数据项的描述;并将这些数据工件映射到数据质量，应用程序和位置。
• Technical架构。例如，了解企业，解决方案或系统的技术基础架构的结构和行为。

我自下而上（需求）观点的架构区域如下所示：

• 正确使用中间件 - 松散耦合，容错，特定于目标的转换，杀死点对点等。
• 尽可能多地识别和设计出对帐。
• 尽可能多地识别和设计双键控。
• 识别并设计尽可能多的手动流程。
• 识别并设计出任何最终用户计算解决方案 - 例如访问数据库，Excel电子表格。
• 识别并设计出任何最终用户编辑“答案” - 在完成所有工作后获取信息，然后进行编辑。
• 调查完整的数据生命周期：谁拥有它，谁丰富它，谁分发它，单一版本的事实，删除对帐。
• 确定性能和可伸缩性指标，针对多个数据配置文件测试风险区域。
• 识别实时与批处理流程和接口，并在可行的情况下消除批处理依赖性。
• 尽可能整合到单一平台，以及单个与多个实例。
• 能够在合理的时间范围内快速处理新的香草业务和新的复杂业务。
• 确定明确的支持模型，特别是在必要时跨区域。
• 状态维护和恢复 - 可以恢复每天处理和接口故障的程度。
• BCP / DR要求和功能，一般容错，WAN依赖性。
• 哪里可以降低项目风险？
• 安全，最终用户和开发人员访问，围绕生产的钢圈。
• MI报告设施到位了吗？
• 尽可能强调简单性，系统取消调试。