作为总体软件设计的一部分，您认为哪些体系结构透视图？

Question

当有人使用XXX架构这个术语时，我往往会畏缩。它经常表明，我可能没有考虑另一种体系结构规则或观点。你正在考虑哪些体系结构的观点，你有什么好的资源来提供关于它们的信息吗？

我希望这能帮助其他正在努力通过建筑行业的人。

• 生存性
• 绩效管理
• 业务监测与管理
• 服务导向
• TOGAF定义了许多服务质量属性。

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

Answer 1

体系结构和体系结构决策主要是关于系统的“非功能性”需求；pace RoadWarrier，但是他提到的每一件事情都是体系结构决策的结果，而不仅仅是它们本身的独立性。(证据:在这些领域中，是什么导致了特定的选择？它总是需要满足一些非功能性的需求。)

考虑到这一点，这是两个部分的问题。首先，您需要决定哪些NFR是重要的。最好是用严格的方法来说明它们，例如，不要仅仅说“高度可用”，比如“系统必须可用(MTTF/(MTTF+MTTR)) 99.99 %，最长的单次停机时间为4分钟”。

其次，您需要考虑哪些视图将帮助您设计以满足这些需求并证明您的决定是合理的。取决于您的需求的严格性，这可能是从白板方框图到正式的模拟研究。

例如，在业务域中，例如在通过web接口可用的IT系统中，您可能希望：

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

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

Answer 2

• 可测性
• 可扩展性
• 容错
• 性能下降(人们希望是优雅的)
• 可升级性(硬件和软件)

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

Answer 3

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

架构和architect都是负载过重的术语。首先，您需要指定是指软件公司(软件是产品/服务)还是业务公司(软件支持产品/服务)。

还有自上而下的体系结构视图(从组织的角度来看，重要的是什么)和自下而上的视图(从项目需求的角度来看，重要的是什么)。

在一家大型企业中，从自上而下(组织)的角度来看，架构通常是这样划分的：

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

从自下而上(需求)观点看，我的体系结构区域如下所示：

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