DDD的基本原则
- （1）保持语言、模型、代码三者一致
语言：开发团队与领域专家沟通使用的自然语言。因为它与设计模型、代码是一致的，所以也称为通用语言。
模型：设计的输出物，是对领域逻辑的精准建模。模型会充分体现具有领域含义的术语和关系。
作为通用语言的核心，模型既充当着沟通业务逻辑的媒介，也直接指导开发实现。
代码：模型和通用语言在实现层的精确表达。 - （2）保持领域模型的独立性和内聚性
独立性：领域模型可以被独立开发、测试和验收，与系统架构中的其他任何部分都没有依赖关系（只会被依赖）。
内聚性：关联紧密的业务逻辑要通过模型组织在一起，不宜分散。模型不包含除领域逻辑之外的其他内容，
且领域模型是业务逻辑的唯一载体，一处业务逻辑只能存在于一个模型内。 - 通用语言应该是以消除了所有歧义之后的业务语言为基础，以领域模型为核心，以需求为边界，由领域专家和技术团队共同打造的沟通媒介
- 软件工程的三个基本要素，复杂度控制、架构原则和团队协作
软件架构的6个原则
-
1：语义一致性（Semantic Coherence）原则：相同的逻辑，代码中只能有一个处理的地方。不会为做同一件事情提供两种方法。
（DDD）所有的业务逻辑都必须封装在领域模型中，领域模型是调用业务逻辑的唯一入口，保证了“一处逻辑只有一处代码”的原则 -
2：开闭（Open-Closed）原则：软件模块对于需求应该是可以扩展的，但对于代码修改是关闭的
技术上则可以采用接口、事件、晚绑定、多态、参数化和配置文件等各类形式。
“把系统中稳定的部分与变化的部分分开管理”这一说法也是开闭原则的延伸 -
3：最简（Minimize）原则：用最简单的机制来满足需求，不要引入不必要的组件、框架等，用极简的方式添加功能，
会得到更健壮的系统 -
4：高内聚低耦合（High Cohesion & Loose Coupling）原则
内聚指的是模块内部的关系。高内聚即关系紧密的逻辑整体要组织到一起，每个模块都要有清晰定义的角色，
不相关的逻辑不要放在一起。
耦合是模块之间的关系。低耦合是说模块之间的依赖关系要尽可能少，依赖类型要弱，甚至完全不知道彼此最好 -
5：关注点分离（Separation of Concern）原则：彼此不相关的关注点应该在架构组织上将它们分离，而不应该放在一起彼此影响
-
6：可构建、可测试（Buildable & Testable）原则：容易被理解的，支持增量式构建并且方便测试
- DDD适用性评分表
- 测试、过程和架构的最佳搭档 -
1 测试的最佳搭档：TDD和单元测试
-
2 过程的最佳搭档：敏捷过程和DevOps
-
3 架构的最佳搭档：六边形、洋葱和分层架构
DDD成熟度的5个度量维度（PTSTR）
3级成熟度模型
