Refined Architecture，即细化架构，越是复杂的系统，越是需要从多个方面进行架构设计，这样才能把问题研究和表达清楚，而提供不同的软件架构视图也便于交流和传递设计思想。
关键需求是对软件架构设计起关键作用的需求子集，包括功能需求、质量需求和商业需求三种，架构细化必须注意满足这些需求。
领域模型是以面向对象方式对问题领域的模型的模拟和抽象，它揭示了重要的业务领域概念，并建立业务领域概念之间的关系，领域模型被不断精化后成为最终软件系统的问题领域层，它决定了软件系统的功能范围，并影响着软件系统的可扩展性。
概念性架构是对系统设计的最初构想，通过主要的设计元素及它们之间的关系来描述系统，这些高层次的设计选择对未来软件系统的质量和功能都有关键作用。
约束可以视为一类特殊的需求，它们具有强制性，规定了业务和技术上的标准和限制。
我们利用架构视图的方法，从逻辑架构、开发架构、运行架构、物理架构和数据架构五个方面来进行架构设计。
设计逻辑架构：使用UML来描述，静态方面包括包图、类图、对象图;动态方面包括序列图、协作图、状态图和活动图。
逻辑架构的设计应该完成的工作：
细化功能单元
发现通用机制
细化领域模型
确定子系统接口和交互机制
因为软件架构的重点在于‘软件系统的各部分是如何相关的’，那么我们可以经过适度的抽象分析，将几组协作中的公共行为提取出来成为‘通用机制’，这样用利于所有涉众对软件架构的共同认识——即提高了系统的概念完整性。
细化架构设计是在概念架构之后对顶层设计进行细化的步骤。
想想我们的BA们在设计业务方案时做了些什么：拆分功能到每个组件、依据拆分情况给出组件间交互的流程图/时序图/状态转移图......
功能拆分，即设计逻辑视图；流程图，即设计运行视图。这两个一个静态的职责划分，一个动态的交互刻画，基本上能够涵盖功能增量开发所需的所有元素。常用的架构视图共5个，除了这两个还有物理视图、开发视图、数据视图，系统方案不写这三个视图意味着在增量的业务功能开发中，它们是基本不变的。
物理视图，组件怎样部署。扩展说几句，业务开销峰谷值相近的组件可以部署到同一个核，这样在某些用例下，这些组件开销的剧增不至于波及到其他业务；当然，在某些场景下，也可以把峰谷值相近的组件分开部署，这样能在某些用例下分摊开销。设计物理视图，一般是架构师的日常职责。
开发视图，哪些代码用C哪些用Python，哪些编成库。这些是由架构师在项目初期确定后，由CI团队进行维护和演进的。
数据视图，数据库选型、基础表结构设计，应该由系统架构师SA设计基础文件与表结构，新增需求由守护团队进行维护。
参考：