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

Question

当有人使用术语 XXX 架构时，我往往会感到畏缩。它通常表明我可能没有考虑另一种架构学科或观点。您正在考虑哪些架构方面的问题，您是否有任何关于这些方面的良好信息资源？

我希望这可以帮助其他正在从事建筑行业的人。

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

很抱歉进行了编辑，但您的回答很准确，我认为这个问题需要改进。

Answer 1

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

考虑到这一点，这是一个两部分的问题。首先，您需要确定哪些 NFR 是重要的。最好使用严格的方法对它们进行特定说明，例如，不要只说“高度可用”，而是说“系统必须可用 (MTTF/(MTTF+MTTR)) 99.99%，最长的单次中断时间是4 分钟。”

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

在企业域中，例如在通过网络界面可用的 IT 系统中，例如，您可能希望：

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

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

Answer 2

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

顺便说一句，这些都是我喜欢企业服务总线 (ESB) 的原因！

Answer 3

编辑：由于问题的重点发生了变化，我将答案编辑如下。

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

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

在大型业务线公司中，从自上而下（组织）的角度来看，架构通常是这样划分的：

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

从自下而上（需求）的角度来看，我的架构区域如下所示：

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