系统设计与编写
实体模型是确定系统包含的实体以及它们之间的关联的过程：
- 理清业务概念，统一业务词汇。
- 抽象业务实体，包括事件、人/角色、地点和事物等。
- 识别实体关系：继承、聚合、关联等。
实体模型也叫 ER（Entity-Relation）模型。可以考虑使用四色法建模，一般可以使用类图或组件图表示。需要注意的是一定要理清业务的概念，统一命名和定义业务相关词汇，这是进一步沟通的基础。
首先需要在整体上考虑系统的位置和职责：
- 确定系统在整个上下文中的位置，与其他系统的关联。
- 确定系统自身以及各个外部系统的职责。
整体架构对应的就是情景视图。这一步将系统看作一个黑盒，确认系统自己的范围和职责，相关的外部系统的职责，以及他们之间的关联。
例如，交易系统的整体架构大概是这样的：
设计功能模块
其次需要确定系统内部的功能模块及其职责：
- 确定系统的模块划分。
- 确定每个模块的职责以及模块间的关联。
功能模块对应的就是功能视图。这一步需要明确系统的内部结构。内部模块划分主要有基于业务功能的划分，以及基于实现层次的划分，稍复杂的系统可能会两者都有。也有一些系统会采用CQRS等架构，那么模块划分可能会不一样。功能模块可以使用UML的组件图表示。
例如，下图是一个系统模块示意图：
一旦确定了关注的重点，在设计和开发的每个过程中，我们都要把这个重点放在心上。
例如，对于订单系统，因为涉及到钱和交易，数据的一致性和可追溯性极其重要。下单和支付的API都必须是幂等的，每一笔收入变动都必须记录日志，必须有严格的核对和对账。为了安全，每一次API调用都必须进行权限验证。
例如，亚马逊有个知名的原则，所有的系统间调用都必须通过定义清楚的 API，不允许共享数据库。这也是一个架构原则。
