系统与子系统
系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。
子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。
例如:汽车与发动机
模块与组件
都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。
模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。
组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。
框架与架构
框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。
框架是规范，架构是结构。
架构：软件架构指软件系统的顶层结构。
架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.并由它来指导团队中的每个人思想层面上的一致。
涉及四方面：
系统性思考的合理决策：比如技术选型、解决方案等。
明确的系统骨架：明确系统有哪些部分组成。
系统协作关系：各个组成部分如何协作来实现业务请求。
约束规范和指导原则：保证系统有序，高效、稳定运行。
因此架构师具备能力：理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施。
架构设计完全是为了业务，
- 需求相对复杂.
- 非功能性需求在整个系统占据重要位置.
- 系统生命周期长,有扩展性需求.
- 系统基于组件或者集成的需要.
- 业务流程再造的需要.
从架构设计角度，以下三点是最为关键的：
- 让我们的模型、组件和业务划分尽量靠近变化的本质，比如对于一般电商系统来说，就是用户、商品、交易、支付等，这样的划分能够让我们将变化“隔离”在一定的范围(业务模块)内，从而帮助我们有效减少改变点。
- 设计上，业务模型内部是高内聚，模型之间是低耦合，即各自完成的业务是相对独立的，不会因为一方掉线而牵连另外一方，比如商品推荐功能挂掉了，但是交易和支付业务应该继续正常提供服务，可能提示用户暂时无法提供推荐服务，或者干脆降级为兜底策略。
- 模型、组件在业务上尽可能是复用的，正是这样的复用才成就了今天的互联网级架构，我们不会每做一个电商系统都从零做起。而被“复用”最多的业务模块显然会重点设计和运营，成为核心业务模块。当然架构上这样的电商系统必然也会比较健壮。
1.战略建模
定义好界限上下文
在战略层面，DDD非常强调对业务问题的分析和分解，通过识别核心问题来降低问题的复杂度。DDD 在战略层面维护模型的概念完整性的方法，最重要的两个概念就是界限上下文(Bounded Context)和防腐层(Anti-Corruption Layer)
划分上下文的规则，“高内聚、低耦合”。与其关注上下文的“大小”，不如关注模型的“质量”，关注概念的完整性是不是容易被破坏。判断大小是不是合适，要结合应用开发团队的能力，看开发团队能在多大的一个范围内掌控软件的概念完整性。只要是开发团队没有问题，这个范围就算再大也都是可以的。如果开发团队的水平在业界属于上游，那么维护上下文的范围往往是很大的;一些公司开发团队的水平参差不齐，所以在项目的实施过程中，可能需要划分相对小的上下文，尽可能减少“屎山”的不断堆积。
做好防腐层
界限上下文需要时刻保护好自己所维护的边界，以及边界内概念的完整性，这时需要将某个上下文的概念转化为另一个上下文概念的地方就叫做“防腐层”。防腐层的实现有很多种，典型的比如作为适配器 Adaptor 来实现，另外广义上讲，Gateway 也是一个典型性的防腐层组件，当然，防腐层的代码和其他内部业务模型之间要存在明显的物理边界(当然不一定说要把防腐层作为一个个独立部署的进程)，至少我们可以考虑把防腐层作为一个独立的类库来进行构建和维护，阿里内部的比如星环、其实就是这个思路。
2.战术建模
DDD 在战术上最核心的概念就是实体和聚合，“聚合是数据修改的单元”，基于这个原则，我们可以做到“聚合内强一致、聚合外最终一致”。