针对核心域内的业务概念进行领域建模，通过聚合、实体、值对象的识别，为技术实现提供参考。
核心领域模型几个核心的模型，是对业务的高度抽象，利用抽象模型作为业务和系统实现的核心联系，领域模型封装和承载了全部的业务逻辑，并通过聚合的方式保持业务的“高内聚，低耦合”。
聚合（Aggregate），负责封装业务逻辑，通过一致性边界和统一语言，容纳实体与值对象。聚合有一个聚合根和上下文边界。实体（Entity），是聚合的主干，具有唯一标识和生命周期。聚合根（Aggregate Root），是一种实体，是聚合的根节点。值对象（Value Object），是附加业务的实体概念。一个限界上下文内能包含多个聚合，但是聚合只能在一个上下文中，对业务问题进行最细粒度的澄清和划分。
领域建模目标是软件架构在模型层面上的内聚和解耦。同时对实现时的服务粒度，接口能力提供指导。
实体实体是领域模型中常见且非常重要的概念，它重要特征三点：
有属性有行为，有业务逻辑处理能力，不仅是数据模型。有生命周期，可跟踪的持续变化，但是标识不变。有标识且在聚合中唯一。DDD推荐的实体是充血模型，特殊场景下也可以贫血模型，重点在于业务逻辑处理能力，可以不断丰富属于自身的行为，要保持专注，一些相关的行为可以委托给值对象或领域服务。
1，发现实体
开发团队与领域专家详细讨论出限界上下文中的通用语言，明确了概念术语。将这些概念的名词再次抽象成为实体及其属性。也可能是值对象，领域服务等。
2，实体的关键行为
概念术语的名词抽象为实体，那么其动词或动作将抽象为实体的行为，重点关注代表了实体的角色与职责的关键行为。也可能是领域事件等。
3，跟踪变化
跟踪那些持续改变的状态，对于变化可能需要发布领域事件。
值对象值对象最简洁理解是属性的集合，不具有实体的强特征，只表示起描述性作用的并且可以相互替换的概念。在多个限界上下文之间进行集成时，也通常使用值对象。建模过程优先选择值对象，对外干扰最少。
是否将领域概念建模成值对象，需要考虑通用语言，以及它的特征：
度量与描述领域中的一个事物。可以作为不变量。可以把多个不同的相关属性组合成一个概念整体。可以替换。不会对协作对象造成副作用。聚合与聚合根完成实体和值对象的抽象后，将它们组成聚合，再根据业务语义将多个聚合划定到同一个限界上下文中，并在限界上下文内完成领域建模。
聚合的作用：
业务和逻辑紧密关联的基本业务单元，实现共同的业务逻辑并保证数据一致性。在一个上下文边界内实现业务单一职责和高内聚。在不同的聚合之间松耦合。聚合根的作用：
聚合根是实体，也叫根实体，聚合内的管理者，协调各实体与值对象完成共同的业务逻辑，统一了业务规则控制。在聚合之间，是对外的接口人，接收外部请求，完成聚合之间的协同。在限界上下文和实体之间增加聚合和聚合根的概念，让实体和值对象协同工作，在实现公共业务逻辑的时候，可以保证数据的一致性。
聚合的设计原则：
高内聚，聚合用来封装真正的不变性，将与该聚合无关的业务排除在外。需要在内部完成事务强一致性。聚合尽量小，使用根实体来表示聚合，只有最小数量的属性。其他的建模为值对象或排除在外。聚合之间通过id关联，不依赖对象费用则边界清晰。边界之外使用最终一致性，不同聚合之间最终一致性。类似业务可以用领域事件等方式异步修改相关的聚合，实现聚合间解耦。在应用层实现跨聚合的调用。也有特殊情况下会打破以上的设计原则，如用户界面的友好性，暂时无消息、定时器等技术，不得已的全局事务，查询的性能要求等。
其他辅助模型领域服务，对于有些领域概念，不能放在实体上，也不能放值对象上，就可以使用领域服务了。它并非对等于一个应用服务，也可能是一个基础设施层的组件或Jar包。对外有公开接口、转换服务、迷你层等来提供服务。领域事件，需要使用最终一致性取代了事务一致性时，就可以使用领域事件来解决。通常发生在解耦聚合之间的涉及多个聚合修改的业务，或者本聚合内稳定性与性能要求。资源库，处理对象持久化，获取对象。只有聚合才有相应的资源库。
