领域
领域或领域模型是使项目独特的东西。考虑到正在解决的问题的需求和术语 （问题上下文），您构建一个由实体、它们的关系以及操作这些实体的逻辑组成的 抽象。为了专注于问题的复杂部分，领域理想情况下应与 系统的基础设施部分分离（即如何将数据保存到数据库、如何形成 HTTP 响应等）。
NOTE
这种隔离适用于复杂系统。如果您的项目领域基本上是对一组记录的创建/读取/更新/删除， 没有太多复杂逻辑，那么将复杂解决方案应用于简单问题是没有意义的。 下面的领域设计的各个概念可以单独应用，因此即使您的 项目没有那么复杂，也请确保查看这些内容。
限界上下文
几乎不可能构建一个能解决多个问题且本身不太复杂的模型。因此，将领域划分为几个用例并为每个用例建立单独的模型是一种良好实践。这种分离的模型被称为“限界上下文”。
构建块
在描述领域模型时，通常使用各种构建块。并非必须使用所有构建块。
实体
实体是可唯一标识的对象，例如用户、产品、付款等。比较它们时，您检查的是 ID，而不是属性值。如果有两个属性不同但 ID 相同的对象，则认为它们是同一个事物。
值对象
值对象通过其特征来描述对象。例如，由数值和货币组成的价格。比较此类对象时，您检查的是实际值。如果它们匹配，则认为对象相同。
聚合
聚合是一组可视为单一单元的领域对象（如实体、值对象）和附加数据。它通常代表领域模型中的复合对象，例如商店订单或人力资源人员档案。
聚合的一个组件称为根。根将聚合标识为一个整体，应通过根来访问聚合。
领域事件
聚合在处理过程中可能会引发事件。例如，当订单确认时，会触发 OrderConfirmed 事件，以便系统的其他部分可以响应这些事件。
数据传输对象
数据传输对象（DTO）是一种仅用于保存数据的对象。它通常用于在不同服务之间传递数据。
服务
服务是一个包含领域模型上下文中独立操作的类。请参阅“服务组件”。
仓库
仓库的任务是抽象化获取领域对象的方式。这些通常分为两部分：保留在领域层的接口和位于基础设施层的实现。这样，领域不关心如何获取和保存数据，可以专注于复杂的业务逻辑。
仓库通常作为服务实现。
实例化构建块
实体、值对象、聚合和领域事件不是服务，不应通过 DI 容器实例化。使用 new 是实例化这些对象的正确方式。