1、实体（Entity）
实体（Entity）扮演着核心角色，是构建领域模型的关键构件之一。具有唯一标识的对象，其身份不会因其属性的改变而改变。实体通常代表业务领域中的关键概念，如用户、订单等。
实体是模拟现实世界业务实体的关键概念，其独特之处在于每个实体都有一个唯一标识符（Identity），即使两个实体在属性上完全相同，通过这个唯一标识也能将它们区分开。这个标识通常采用ID或唯一键的形式，确保了实体在其整个生命周期内的持续追踪。实体的另一个特性是它们的持久性，需要被持久化存储以保证其状态能够在不同的系统状态和操作期间被稳定识别和管理。不同于值对象，实体的状态是可以变化的，但这些变化不影响实体的身份，其行为变化通常导致状态的更新。实体还封装了领域逻辑，定义了它的行为及与其他领域对象的交互方式，不仅仅是数据的简单集合。最后，实体拥有一个从创建到销毁或归档的完整生命周期，在这一过程中可能会经历各种状态变化和参与多种领域操作。
实体的使用使得领域模型能够更加贴近现实世界的业务情景，因为它们模拟了具有唯一身份和可变状态的业务实体。在设计领域模型时，识别哪些领域概念应当被建模为实体是非常关键的，因为这会影响到模型的清晰度、灵活性和可维护性。通过恰当地使用实体，开发者可以在保持业务逻辑一致性的同时，管理和维护领域中的复杂状态和行为。
2、值对象（Value Object）
值对象（Value Object）是一个核心概念，它代表了领域中的一些元素，这些元素是通过它们的属性来描述的，而不是通过一个唯一标识符。值对象的特点是它们是不可变的，一旦创建就不能更改。如果需要修改，就必须创建一个新的值对象。通过属性值定义的对象，没有唯一标识。值对象应该是不可变的，这意味着一旦创建，其状态就不应该改变。它们通常用于表示量度、描述等概念，如货币金额、地址等。
值对象提供了一种通过其属性直接表示领域概念的方法，极大地提高了模型的表达力和丰富性。它们的不可变性保证了对象状态一旦创建便不会改变，有效避免了副作用和数据一致性问题，增强了模型的稳定性。此外，值对象由于缺乏唯一标识，能够在不同的上下文中被重用，这不仅提高了代码的可维护性和复用性，还简化了开发过程。值对象的一个关键特性是它们通过属性值进行比较，而非身份标识，使得逻辑上的比较更加直接和有意义。这些特点共同作用，使值对象成为领域模型设计中不可或缺的一部分，有助于构建更加准确和高效的软件系统。
值对象在领域模型中广泛用于表示那些重要的，但不需要唯一标识的概念，例如，货币和金额、日期范围、地址等都可以被建模为值对象。通过将这些概念建模为值对象，开发者能够创建出更加丰富、表达性强且安全的领域模型。
值对象的设计应该关注其不可变性和如何通过构造函数确保其完整性和有效性。此外，考虑到值对象的可重用性和比较逻辑，开发者需要仔细设计值对象的公共接口，确保它们能够在不同的上下文中以一致的方式使用。
3、聚合（Aggregate）
一个聚合是一组实体和值对象的集合，它们被视为一个单元进行数据更改。每个聚合都有一个根实体，称为聚合根（Aggregate Root），外部对聚合的任何访问都应该通过聚合根进行。聚合根（Aggregate Root）是聚合中的一个实体，它是外界与聚合内部其他对象交互的唯一通道。聚合根拥有全局唯一的标识符，而聚合内的其他实体可以通过局部唯一的方式标识。边界定义了聚合内部和外部之间的交互规则，确保聚合的内部状态只能通过聚合根以受控方式改变，这有助于保持业务规则的一致性和减少错误。
使用聚合的目的是将领域模型中相关的对象组织成一个高度内聚的集合，同时限制它们与外部世界的交互，以管理领域复杂性。
聚合通过将相关对象组织在一起，提高了模型的清晰度，帮助开发者更好地理解领域模型中不同部分之间的关系。其次，聚合通过确保所有对内部状态的更改都遵循业务规则，有效地保证了业务规则的一致性，显著减少了不一致性的风险。聚合通过限制对象之间的直接关联，简化了系统设计，减少了系统中的潜在复杂性，使得维护和开发工作变得更加容易。这些好处共同作用，使聚合成为管理领域复杂性、提升模型效率和清晰度的强有力工具。
设计良好的聚合是实现领域模型的关键，它们应该围绕业务功能进行建模，而不是简单地反映数据库结构。选择合适的聚合大小和边界是一个挑战，需要仔细考虑领域的业务规则和实体之间的关系。过大的聚合可能会导致管理难度和性能问题，而过小的聚合可能无法充分利用DDD带来的优势。因此，聚合的设计应该随着领域知识的增长而不断调整和优化。
4、领域服务（Domain Service）
在领域模型中执行特定业务操作的无状态服务。当某个操作不自然属于任何实体或值对象时，它应该定义在领域服务中。领域服务通常用来封装领域逻辑，特别是当一个操作或业务规则跨越多个领域对象时，这些逻辑就不适宜放在单一的实体或值对象中。
领域服务扮演着封装领域逻辑、实现状态无关操作、跨领域对象协作、支持重用和组合以及界定清晰责任范围的关键角色。它们负责封装那些对于领域模型有意义但不归属于任何单一领域对象的特定操作，通过参数接收数据，执行必要的业务逻辑，并返回结果，而不维持任何内部状态。领域服务的设计允许跨越多个实体或值对象的操作，处理涉及核心业务规则的复杂场景，这些规则的实施往往需要多个领域对象的合作。
领域服务的可重用性和组合能力增加了系统设计的灵活性和复用性。每个领域服务都有明确和限定的责任范围，确保了模型的清晰度和领域逻辑的易于管理。这种方法不仅体现了DDD对清晰模型和维护性的重视，还确保了业务逻辑的有效实现和封装。
通过定义领域服务，DDD的战术设计允许开发者在保持模型清晰和维护性的同时，有效地实现和封装业务逻辑。领域服务的使用，确保了领域模型既能反映业务的复杂性，又能保持设计的优雅和简洁。
5、仓库（Repository）
提供了一种从持久层查询和保存聚合的方法，使得应用层不需要关心数据存储的细节。仓库通常对应于聚合根，每个聚合根有一个仓库接口。仓库（Repository）是战术设计中的一个关键模式，它为访问领域对象提供了一个集合式的接口，抽象了持久化机制的细节。
仓库模式起着至关重要的作用，它不仅封装了数据的持久化逻辑，如数据库访问，从而使应用层无需直接接触数据存储的细节，保持了领域层的纯洁性和业务逻辑的集中，而且提供了一个类似操作集合的接口，使得领域对象的访问、添加、移除、更新和查询操作变得直观易懂。此外，仓库的设计还非常注重领域模型的完整性和一致性，通过管理领域对象的生命周期操作（例如保存、更新、删除）来实现。它还通过内部封装复杂的查询逻辑，并对外提供简洁的接口，从而使应用层不必担心数据检索的具体实现细节，简化了开发过程。总的来说，仓库模式通过这些策略显著提高了系统的可维护性和可扩展性，同时促进了领域逻辑与基础设施代码的有效解耦。
仓库模式在领域驱动设计中封装了存储逻辑，其实现依赖于基础设施层，这层处理数据持久化和访问的技术细节，如ORM框架。仓库的实现可能根据所用技术栈有所不同，但一般会遵循几个通用原则。仓库接口应定义在领域层，其实现则放在基础设施层或应用层，这样做有助于解耦领域模型和数据持久化技术。仓库设计需以领域模型的需求为导向，确保提供的接口能够支持领域内的操作。为了满足数据访问性能的要求，仓库实现中可能需要加入特定的优化措施，如使用缓存或特定查询语言技术。这些考虑确保了仓库能够有效地支持领域逻辑，同时提高系统的性能和可维护性。
通过仓库模式，DDD实现了对领域对象的高效管理和访问，促进了领域逻辑和基础设施代码的解耦，提高了系统的可维护性和可扩展性。
6、应用服务（Application Service）
应用服务负责处理应用程序的业务用例和数据流，协调领域对象（如实体和值对象）来执行具体的业务逻辑。定义了软件要执行的应用逻辑，作为领域层和用户接口之间的传递层。应用服务协调领域对象执行任务，但本身不包含业务逻辑。
应用服务是处理业务用例和数据流、协调领域对象执行业务逻辑的关键组成部分。它们的主要职责包括协调工作流，即调用领域层的服务或实体来执行业务规则；管理事务边界以保持业务操作的完整性和一致性；实现安全策略，如身份验证和授权，确保只有授权用户可以执行操作。此外，应用服务提供清晰的接口供外部调用，封装领域模型的复杂性，并提供简化的操作和数据传输对象（DTOs），以便于与外部系统的集成，处理外部请求并将结果映射到领域概念。
应用服务的定义清晰区分了它们与领域服务的不同。虽然领域服务直接实现领域逻辑，应用服务则侧重于使用这些领域逻辑来满足外部请求的需求。通过这种方式，DDD支持将应用逻辑与业务逻辑分离，促进了代码的清晰组织和维护，同时提高了系统的灵活性和可扩展性。