发展业务- DDD还是非DDD？

Question

我有一个项目，我已经在处理一个传统的3层体系结构(实体/业务/ UI)，我正在应用存储库模式和IoC。

这里的想法是，我们是业务所有者，但业务正在发展，不能说实际上有最终的领域并准备实施。我的实体不包含复杂的业务，我将业务逻辑保留在业务层。

虽然我们已经在使用存储库模式和IoC，但迁移到DDD真的有额外的价值吗?我应该将业务合并到实体中吗？

假设这是最好的做法，编辑会：

• 将实体层合并到业务层，而不是分离 (为了避免循环引用，因为根据我的理解，实体可以有行为，甚至可以调用业务服务)
• 在适用的情况下，将一些业务服务行为迁移到域实体中是创建域模型的第一步？

More

设计

成功实施DDD的先决条件：

• 您的域不是微不足道的。
• 项目组有OOP/OOD方面的经验和兴趣。
• 您可以访问域专家。
• 您有一个迭代过程。

Answer 1

这几乎不是什么问题。

来自业务层的方法是否只适用于某个类的单个实例？把它搬到教室里去。

它是否适用于集合、几个不同的类和/或逻辑更复杂？可能没有通用的答案，无论您决定什么，不要引入循环依赖并尝试打破现有的依赖--迟早，当需要进行重构时，您会对此感到感激。

完成之后，检查API并尽可能地从其中删除。

Answer 2

DDD的主要思想不仅仅是使用存储库，它与IoC无关，它是关于拥有一种业务无处不在的语言，并根据反映业务的实体和值对象来设计您的域层，这样您就需要真正以面向对象的方式对其建模，其中对象封装数据并包含行为，这样应用程序在业务逻辑方面将更加可维护，并且通过使用诸如抽象、多态性、组合等面向对象的技术可以扩展。

所以答案是肯定的

Answer 3

您可能会在域模型和DDD之间产生混淆。领域模型是一种体系结构模式，其中业务实体被实现为OO类，并且使用存储库模式，而DDD是分析和建模业务的一组过程和原则。DDD实际上是一种更加精细和形式化的领域模型实现方法。

无论如何，您不应该需要一个“最终”和“准备实现”的域，因为域模型和DDD都是为不断发展的域模型设计的。

您说业务层包含逻辑而不是实体，而实体实际上是业务层(或域)。

我要说，实现领域模型的开销是最小的，而且从长远来看，随着模型的发展，它几乎总是值得的。