【DDD】概念
简介
DDD是一种开发理念，核心是维护一个反应领域概念的模型（领域模型是软件最核心的部分，反应了软件的业务本质），然后通过大量模式来指导模型设计与开发。
DDD中最核心的是Domain Model（领域模型），和领域模型相对的是事务脚本。领域模型和事务脚本说到底就是面向对象和面向过程的区别。
DDD的好处
- 从技术维度实现分层：能够在每层关注自己的事情，比如领域层关注业务逻辑的事情，仓储关注持久化数据的事情，应用服务层关注用例的事情，接口层关注暴露给前端的事情。
- 降低软件复杂度。接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。DDD是解决复杂中大型软件的一套行之有效方式，在国外已经成为主流。DDD认为很多原因造成软件的复杂性，我们不可能避免这些复杂性，能做的是对复杂的问题进行控制。而一个好的领域模型是控制复杂问题的关键。领域模型的价值在于提供一种通用的语言，使得领域专家和软件技术人员联系在一起，沟通无歧义。
DDD的开发流程
首先通过软件需求规格说明书或原型生成一个领域模型（类、类的属性、类与类之间的关系）；
然后根据模式（应该如何分层？、领域逻辑写在哪？与持久化如何交互？如何协调多对象领域逻辑？如何实现逻辑与数据存储解耦等）指导来实现代码模型。
DDD架构
- 表现层，负责显示和接受输入；
- 应用层，很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；
- 领域层，包含整个应用的所有业务逻辑；
- 基础层，提供整个应用的基础服务；
领域
这是一个范围概念，面向业务的，也就是业务的范围。
领域可划分为多个子领域：
- 核心域：解决项目的核心问题，和组织业务紧密相关。
- 支撑域：解决项目的非核心问题，则具有组织特性。
- 通用域：解决通用问题。
领域模型
对于领域内的对象进行建模，从而抽象出来模型。
我们的项目应该开始于创建领域模型，而不是考虑如何设计数据库和编写代码。使用领域模型，我们可以一直用业务语言去描述和构建系统，而不是使用技术人员的语言。
使用技术人员的语言去描述和实现业务事务。没有太多设计，没有考虑可扩展性、可维护性，流水账地编写代码。
限界上下文
领域驱动设计是基于领域的，领域之间的划分基于限界上下文
限的意思就是划分、规定，界就是界限。上下文就是业务的整个流程，总的来说，可以称限界上下文为业务流程在一个划定的界限中
实体和值对象：
https://www.cnblogs.com/fanfan-90/p/16123965.html
聚合（Aggregate）
目的：高内聚，低耦合。有关系的实体紧密协作，而关系很弱的实体被隔离。
把关系紧密的实体放到一个聚合中，每个聚合中有一个实体作为聚合根（Aggregate Root），所有对于聚合内对象的访问都通过聚合根来进行，外部对象只能持有对聚合根的引用。
聚合根不仅仅是实体，还是所在聚合的管理者。
聚合的判断标准
实体是否是整体和部分的关系，是否存在着相同的生命周期。
聚合的划分的原则
尽量把聚合设计的小一点，一个聚合只包含一个聚合根实体和密不可分的实体，实体中只包含最小数量的属性。
小聚合有助于进行微服务的拆分。
聚合实现（EF Core）
我们可以在上下文中只为聚合根实体声明DbSet类型的属性。对非聚合根实体、值对象的操作都通过根实体进行。
跨聚合只能引用根实体的Id，而不是根实体对象。
即使一个实体类型没有声明对应的DbSet类型的属性，只要EF Core遇到实体对象，EF Core仍然会像对待其他实体对象一样处理。
领域服务与应用服务
聚合中的实体中没有业务逻辑代码，只有对象的创建、对象的初始化、状态管理等个体相关的代码。
对于聚合内的业务逻辑，我们编写领域服务（Domain Service），而对于跨聚合协作以及聚合与外部系统协作的逻辑，我们编写应用服务（Application Service）。
应用服务协调多个领域服务、外部系统来完成一个用例。
领域服务不是必须的，在一些简单的业务处理中（比如增删改查）是没有领域知识（也就是业务逻辑）的，这种情况下应用服务可以完成所有操作，不需要引入领域服务。这样可以避免过度设计。
洋葱架构
洋葱架构从六边形架构发展而来，在中间的核心业务逻辑里又引入了分层。对于洋葱架构来说，应用构建在领域模型上，里层定义接口，外层实现接口。内层的部分比外层的部分更加的抽象，内层表达抽象，外层表达实现。
外层的代码只能调用内层的代码，内层的代码可以通过依赖注入的形式来间接调用外层的代码。
防腐层
外部服务（短信服务、邮件服务、存储服务等）的变化会比较频繁。把这些服务定义为接口，在内层代码中我们只定义和使用接口，在外层代码中定义接口的实现。体现的仍然是洋葱架构的理念。
