DDD架构
一、概念
1. 领域、子域
用来确定范围的，范围即边界。在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。简言之，DDD 的领域就是这个边界内要解决的业务问题域
领域可以进一步划分成子领域，我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围
子域可以根据自身重要性和功能属性划分为三类子域，分别为核心域、通用域和支撑域
3. 核心域、通用域、支撑域
决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力
没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域。比如认证、权限等，没有企业特点，不需要做太多的定制化
支撑域则具有企业特性，但不具有通用性，比如数据代码类的数据字典等系统
4. 通用语言和限界上下文
对同样的领域知识，不同的参与角色可能会有不同的理解。因此 DDD 使用 “通用语言定义上下文含义，限界上下文则定义领域边界”。
通用语言：在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流
限界上下文：限界就是领域的边界；而上下文则是语义环境。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流
业务的通用语言就有它的业务边界，我们不大可能用一个简单的术语没有歧义地去描述一个复杂的业务领域。限界上下文就是用来细分领域，从而定义通用语言所在的边界。比如中文 “在一个明媚的早晨，孩子起床问妈妈：“今天应该穿几件衣服呀？”妈妈回答：“能穿多少就穿多少！””，那么能穿多少就穿多少就是一个通用语言，但是如果单独来看的话，到底是要穿多还是要穿少。因此需要一个限定上下文来指明语义。
因此：每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流。领域内所有限界上下文的领域模型构成整个领域的领域模型。
4. 实体
在 DDD 中有这样一类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致。对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的对象称为实体
领域驱动架构又称DDD模型
https://www.zhihu.com/question/25089273
领域驱动设计靠谱吗：https://www.zhihu.com/question/328870859