领域驱动设计，概念的理解

领域服务（Domain Service）

领域中的一些概念不太适合建模为对象，即归类到实体对象或值对象，因为它们本质上就是一些操作，一些动作，而不是事物。这些操作或动作往往会涉及到多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作。如果强行将这些操作职责分配给任何一个对象，则被分配的对象就是承担一些不该承担的职责，从而会导致对象的职责不明确很混乱。但是基于类的面向对象语言规定任何属性或行为都必须放在对象里面。所以我们需要寻找一种新的模式来表示这种跨多个对象的操作，DDD认为服务是一个很自然的范式用来对应这种跨多个对象的操作，所以就有了领域服务这个模式。和领域对象不同，领域服务是以动词开头来命名的，比如资金转帐服务可以命名为MoneyTransferService。当然，你也可以把服务理解为一个对象，但这和一般意义上的对象有些区别。因为一般的领域对象都是有状态和行为的，而领域服务没有状态只有行为。需要强调的是领域服务是无状态的，它存在的意义就是协调领域对象共完成某个操作，所有的状态还是都保存在相应的领域对象中。我觉得模型（实体）与服务（场景）是对领域的一种划分，模型关注领域的个体行为，场景关注领域的群体行为，模型关注领域的静态结构，场景关注领域的动态功能。这也符合了现实中出现的各种现象，有动有静，有独立有协作。

领域服务还有一个很重要的功能就是可以避免领域逻辑泄露到应用层。因为如果没有领域服务，那么应用层会直接调用领域对象完成本该是属于领域服务该做的操作，这样一来，领域层可能会把一部分领域知识泄露到应用层。因为应用层需要了解每个领域对象的业务功能，具有哪些信息，以及它可能会与哪些其他领域对象交互，怎么交互等一系列领域知识。因此，引入领域服务可以有效的防治领域层的逻辑泄露到应用层。对于应用层来说，从可理解的角度来讲，通过调用领域服务提供的简单易懂但意义明确的接口肯定也要比直接操纵领域对象容易的多。

领域服务是没有状态的，只有行为，行为与状态的理解

在领域驱动设计（DDD）中，”状态”和”行为”是理解领域模型和服务的关键概念。

状态（State）

状态指的是对象在其生命周期中所持有的信息或数据。在面向对象编程中，状态通常通过对象的属性或字段来表示。例如，一个账户实体可能有一个表示余额的属性，这个余额就是账户的状态之一。

在领域服务中，当我们说“领域服务是没有状态的”，意味着领域服务本身不持有任何持久化的数据或信息。它不像实体那样具有可以长期存在的状态。领域服务的职责是处理或协调领域实体之间的交互，但它本身不存储这些实体的状态。

行为（Behavior）

行为指的是对象能够执行的操作或方法。在面向对象编程中，行为通常通过对象的方法来定义。这些方法可以读取或修改对象的状态，或者执行与对象相关的其他操作。

在领域服务中，行为指的是服务所提供的方法或操作。这些方法通常用于处理或协调领域实体之间的复杂交互。例如，在一个转账场景中，领域服务可能提供一个transferFunds方法，该方法接受两个账户实体作为参数，并协调它们之间的转账过程。

操作的最小单元应该是聚合，而不是实体，除非这个实体就是一个聚合

操作的最小单元应该是聚合，而不是实体，不然就是容易乱，除非这个实体就是一个聚合，一个仓储对应一个聚合，一个仓储就是一个事务单元
感觉很重要的概念就是面向对象是有边界的，如果操作没有边界，逻辑就会分散到各处，容易越写越乱，越来越难以管理。
面向对象就是以对象为边界，这个对象的操作只放到这个对象中去。

领域驱动增加了边界范围，外部的操作边界是聚合，而不是一个对象这样一来某件事情的边界就更清晰了
因为很多事情不是一个对象可以完成的，而是要多个对象，多个对象就可以形成一个聚合，聚合中最核心的对象就是聚合根

值对象

https://cloud.tencent.com/developer/article/2181067
https://www.cnblogs.com/skevin/p/16044675.html

SQLSugar对值对象的支持

有值对象的使用实例
https://www.donet5.com/home/Doc?typeId=2576

在领域模型或者是聚合聚合根里边要不要直接调用仓储进行持久化操作

这个问题其实就是，领域模型设计的问题，领域模型设计可以分为：失血模型，贫血模型，充血模型，胀血模型

具体的设计和建议参考：https://www.tnblog.net/aojiancc2/article/details/7304