DDD领域学习

一、DDD的四层领域模型
1、展现层，负责向用户显示信息和解释用户命令，完成前端界面逻辑，并将用户请求传递给应用层
2、应用层，负责协调领域层中的领域对象，组成具体的应用场景，只保留应用任务的进度状态，注重流程性的东西，依赖领域层提供的业务能力
3、领域层，业务软件核心，包含了业务所涉及的领域对象、领域服务以及他们之间的关系、负责表达业务概念、业务状态信息以及业务规则
4、基础设施层，向其他层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制

二、DDD中的贫血模型和充血模型都是领域模型的表现形式，但是它们在设计和实现上有着显著的区别。
1、贫血模型（Anemic Domain Model）是面向过程编程的一种表现形式。贫血模型的实体只包含数据属性和对应的 getter 以及 setter，而具体的业务逻辑交由服务层或其他外部组件负责。贫血模型将数据与操作分离，其好处是模型足够简单，开发上手比较快。团队内多人协作时，设计不容易变形。比较适合轻量级应用。但坏处是贫血模型的实体无法直接体现对应的业务能力，在复杂业务中，梳理业务逻辑将变得非常困难，不利于项目后期的业务演进。
2、充血模型（Rich Domain Model）则是面向对象编程的一种表现形式。充血模型的实体通常包含了数据属性以及引起属性发生变化的核心业务动作。充血模型将数据与业务能力绑定在一起，非常符合业务人员的思考方式，因此其好处是对业务非常友好，有助于更好的封装和保护领域内部的业务规则，尤其适合业务复杂的应用场景。充血模型的坏处是对业务的熟悉程度要求很高，需要在上手之初就设计好针对不同的业务场景，设计好具体的模型实体，并且规划好需要暴露哪些操作，定义哪些业务逻辑。而这些在贫血模型中则不需要，可以边实现边修改。

三、在 DDD 中处理模型的聚合和聚合根
在DDD中，聚合是指一组紧密关联的实体和值对象，它们共同完成一个特定的业务逻辑，并由一个聚合根进行管理。聚合根是聚合的根节点，它作为聚合内堆外暴露的唯一访问入口，负责管理聚合内部的对象状态，并协调它们之间的交互。
处理模型的聚合和聚合根主要涉及以下步骤：
1、识别聚合：在领域模型中，识别出具有紧密关联的实体和值对象，它们共同构成了一个聚合。这些实体和值对象应该符合高内聚、低耦合的设计原则，具有一致的业务语义和行为。
2、定义聚合根：在确定了聚合之后，需要选择一个合适的对象作为聚合根。聚合根应该是一个具有全局唯一性的对象，例如一个订单聚合，包含订单、商品、地址、用户等多个实体，而这其中订单就是一个很好的聚合根。
3、保证聚合内部的一致性：确保聚合内部的对象之间保持一致性，即要么一起成功创建、修改、删除，要么一起失败。聚合根负责协调聚合内部的操作。
4、限制聚合外部访问：聚合形成之后，外部对象只能通过聚合根来访问聚合内的对象。聚合跟负责限制对聚合内部对象的直接访问，以维护聚合的完整性。例如形成订单聚合后，对订单聚合内部的商品、用户进行访问，都必须通过订单实体进行。
5、合理规划业务行为：DDD的设计过程中，更强调对实体状态的变化梳理。因此，一些不会引起实体状态变化的操作，例如查询，就不必要严格按照聚合进行划分。例如，想要一天内卖出了哪些商品，这个操作并不会引起实体状态发生变化，因此就不需要严格按照聚合的要求，先访问订单这个聚合根，再统计订单中的商品。而可以跨过订单，直接统计卖出的商品。
6、暴露聚合的服务：在聚合根中暴露一些服务，以便其他应用程序可以访问聚合内部的数据和业务逻辑。这些服务可以是领域服务或者应用服务，它们应该遵循统一的接口规范，并且应该保证安全性。

四、DDD 中的实体和值对象
在DDD中，实体Entity和值对象Value Object是两个基本的概念，之间有些重要的区别
1、唯一性：实体是唯一的，每个实体都有一个唯一的标识符，即使它的属性在一段时间内发生了变化，它仍然是这个实体。与之不同，值对象可以有一组属性，这些属性可以描述一个事物的状态或特征，但它们没有唯一的标识符，即使两个值对象的属性完全相同，它们也被视为两个不同的对象。
2、状态变化：实体可以有状态，并且可以在不同的时间或场景下有不同的状态。例如，一个订单实体可能在创建时是一个待支付状态，支付后变为已支付状态，而值对象通常只有固定的属性，不会有状态变化。
3、生命周期：实体有一个明确的生命周期，它可能随着时间的推移而创建、更新或删除，而值对象没有自己的生命周期，它们通常是在需要时创建，并在不再需要时被垃圾回收。
4、相等性：对于实体来说，两个具有相同标识符的实体是相同的，无论它们的状态如何。对于值对象，两个具有相同属性的值对象被认为是相等的，但这需要通过比较它们的属性来确定。

五、DDD中处理领域对象的持久化
在 DDD 中，领域对象的持久化工作通常是通过仓库 Repository 和工厂 Factory 实现的。仓库是一种用于访问领域对象的机制。他负责将领域对象从内存中保存到持久存储，如数据库，中，以及从持久存储中检索领域对象。而工厂则负责从持久存储中组装领域对象。
1、定义仓库接口：为每个需要持久化的领域对象创建一个对应的仓库接口。这个接口通常包含了一组方法，用于对领域对象进行存储和检索操作。而在实现仓库接口时，通常可以使用泛型，扩大接口的适用场景。
2、通过工厂组装实体：DDD中的实体包含很多面向对象的业务特色，而数据库中的数据往往带有很多技术特色。这时，通过工厂的设计，可以让实体设计摆脱具体数据库的限制，从而让实体能够真正面向业务进行构建而不用考虑具体数据库技术的影响。
3、合理进行业务隔离：在DDD中，数据的访问和修改应该通过仓库和工厂来完成，而不是直接访问数据库。仓库和工厂应该提供统一的接口来访问和修改数据，这样可以保证数据的完整性和一致性。
4、事务管理：在处理领域对象的持久化时，通常需要考虑事务管理。确保在保存或检索领域对象时，事务能够正确地提交或回滚，以保持数据一致性。
5、隔离异常：与数据库的交互过程中产生的异常，应该在仓库和工厂中进行封装。这些业务异常尽量不要蔓延到领域层。

六、领域驱动设计中的CQRS模式
领域驱动设计（DDD）中的CQRS模式是一种架构模式，它将系统中的操作分为两类：命令（Command）与查询（Query）。CQRS 模式强调了应用程序要将命令和查询愤慨处理。
1、命令是对会引起数据发生变化的操作的总称，如新增、更新、删除等操作。命令通常是不返回数据的，它们只用于触发状态变化。
2、查询则是对不会对数据产生变化的操作的总称，例如按照某些条件查找数据。它们用于获取系统状态的快照或特定信息。查询通常返回数据给客户端
在CQRS模式中，命令和查询应在两个独立的系统中处理，这两个系统一般是指两个独立部署的应用程序，在某些特殊情况下，也可以部署在同一个应用内的不同接口上。通过分离职责、使用不同的数据存储和事件驱动的方式，允许更好地满足系统的性能和可伸缩性需求。
在使用CQRS模式时，通常也需要面临一些问题，例如事务和查询模型的设计。在事务方面，由于命令和查询分别在不同的系统中处理，因此需要解决时间差问题以及更新操作失败可能导致的数据不一致性问题。在查询模型设计方面，需要解决查询接口过多的问题，可以将属于同一领域的查询集中管理作为整个查询系统的一个上下文，或者将它们独立出来作为一个微服务。

七、DDD中处理跨多个实体的复杂业务
在DDD中，跨多个实体的复杂业务通常需要交由领域服务进行协调。领域服务的设计应该遵循以下原则：
1、定义服务接口。领域服务应该定义一个清晰的接口，这个接口应该包含需要实现的方法和参数。这样可以使得其他模块能够使用这个服务而不需要关心具体的实现细节。
2、实现业务逻辑。领域服务的实现应该包含具体的业务逻辑，这是领域服务的核心。业务逻辑应该根据业务需求进行设计和实现，可以跨越多个聚合或领域。
3、暴露业务数据。领域服务可以暴露一些业务数据给其他模块使用，但是需要注意数据的封装和安全性。对于敏感数据，应该遵循最小权限原则，限制其他模块的访问权限。
4、尽量减少依赖。领域服务应该尽量减少对其他模块的依赖，这样可以使得领域服务更加独立和可维护。
5、考虑可测试性。领域服务的实现应该考虑可测试性，使得我们可以方便地对领域服务进行单元测试和集成测试。
6、定义服务调用方式。领域服务可以定义为本地服务或远程服务，根据业务需求和系统架构进行选择。对于远程服务，需要考虑网络通信、服务调用的性能和安全性等方面的问题。

八、DDD中限界上下文的概念和作用
在DDD中，"限界上下文"是一个非常重要的概念，它指的是一个边界内的领域模型和与之相关的语义环境。限界上下文（Bounded Context）是一种用于定义和隔离领域模型的概念。每个限界上下文都代表了一个明确定义的、有边界的领域模型，用于描述业务领域的一部分。限界上下文有助于在大型系统中管理和组织复杂的领域模型，并确保不同部分之间的一致性和清晰性。
限界上下文可以看作是一种语义上的边界，它可以将领域模型与外部环境隔离开来，保证领域模型的独立性和纯净性。在这个边界内，领域模型的概念和操作都有着明确的含义，不会受到外部因素的干扰和影响。
通过限界上下文，团队成员可以更加清晰地了解业务领域，并在这个边界内进行交流和协作。限界上下文可以帮助团队成员避免使用不准确或歧义性的术语，使交流更加准确、高效。
另外，限界上下文还可以作为微服务设计的重要参考。在微服务设计中，不同服务之间的边界是很重要的，而限界上下文可以帮助我们更好地理解和规划这些服务的边界。在很多情况下，限界上下文的边界往往就是微服务的边界，这可以帮助我们更好地拆分和设计微服务。

九、微服务架构中使用领域驱动设计
在微服务架构中使用领域驱动设计（DDD）可以帮助我们更好地理解和设计业务领域，以下是在微服务架构中使用DDD的一些简洁的步骤：
1、定义微服务边界，每个微服务对应一个限界上下文，有自己的领域模型和语言。
2、使用领域模型来建模每个微服务的核心业务逻辑，包括实体、值对象、聚合、领域服务等。并定义它们之间的关系和交互。
3、明确微服务之间的接口和通信协议，如HTTP/REST或AMQP等。基于领域模型定义接口。
4、使用事件驱动架构来确保微服务之间的数据同步。
5、每个微服务拥有自己的仓库与工厂，负责数据的管理和持久化。
6、团队结构应该反映微服务的划分，每个团队专注于自己的微服务。
7、自动化部署和运维，使用监控工具来跟踪微服务性能。
8、不断迭代和改进微服务，根据反馈优化系统。