我的DDD逻辑属于哪里？

Question

我已经被Eric Evans的书所说服,并且正在将DDD集成到我的框架中.所有基本元素(服务,存储库,有界上下文等)都已实现,现在我正在寻找有关如何正确集成它的反馈.

我有一些业务逻辑,必须在创建或修改实体时执行.这个例子非常简单.大多数业务逻辑将变得更加复杂.

此业务逻辑可以拆分为以下操作:

1. 更新计算字段;
2. 更新聚合根目录中的子记录.创建聚合根时,需要创建默认子记录.更新聚合根时,如果聚合根上的特定字段已更改,则需要删除现有子记录并创建新记录;
3. 将聚合根的开始和结束日期传播到聚合根目录中子记录的开始和结束日期.在某些情况下,这些必须保持同步;
4. 将聚合根的字段传播到不同的聚合根.

我的第一次尝试是将所有这些放在聚合根上,但我觉得这不会起作用.我在集成此逻辑时遇到以下问题:

• 所有这些行动必须作为一个整体完成,不应作为单独的行动提供.结果是这将很难测试(TDD);
• 我不清楚是否可以将这些操作转移到服务中.这样做的原因是它们在聚合根之外没有意义,但它会使TDD更容易;
• 某些逻辑会根据是创建新实体还是修改现有实体而更改.我应该将这两个分支放在更新逻辑中,还是应该创建两个完全不同的路径,这些路径共享不区分创建/修改的业务代码.

任何有关上述问题的帮助都将受到高度赞赏,并提供其他反馈意见.

Answer 1

你描述的算法应该保留在聚合根中,否则你最终会得到一个贫血的域模型,除了将一个字段传播到另一个聚合根,我将在后面描述我认为你应该做的事情.

就TDD而言,在聚合根上具有"包"访问权限的方法(例如"calculate()")应该协调整个操作,服务或存储库对象通常会调用该操作.这是测试应该在设置实例变量的不同组合.聚合根应该公开它的实例变量,子集合,每个子节点应该通过getter公开它的实例变量 - 这允许测试验证它们的状态.在所有情况下,如果你需要隐藏信息使这些getter包或私有访问,并使用您的单元测试框架将它们公开用于测试目的.

对于您的测试环境,考虑模拟存储库对象(您正在使用依赖注入吗？)来返回硬编码值.考虑使用像dbunit这样的东西来处理已知状态的数据库.

就逻辑变化而言,创建与修改有关,您指的是如何持久存在或者是否需要考虑实际算法？如果是前者,我会让存储库负责,如果后者我会做两个单独的方法(例如"calculateCreate()"和"calculateUpdate()"),其中calculate()会根据需要进行委托.

此外,还有一个并发问题需要考虑,因为它听起来好像计算值依赖于可变字段.因此要么需要小心锁定,要么只能由客户端一次使用的聚合根.这也适用于跨聚合传播字段 - 我可能会将存储库用于此目的 - 但您需要仔细考虑这应该或不应该影响使用存储库对象的其他客户端.