不断发展的业务 - DDD 与否？答案

【问题标题】：Evolving Business - DDD or Not?不断发展的业务 - DDD 与否？
【发布时间】：2011-12-08 18:31:26
【问题描述】：

我有一个项目，我已经在使用传统的 3 层架构（实体/业务/UI），并且正在应用存储库模式和 IoC。

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

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

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

将实体层合并到业务层而不是分开

(避免循环引用，因为实体可以有行为甚至在我的理解中调用业务服务）
将一些业务服务行为移动到适用的域实体中是拥有域模型的第一步吗？

Prerequisites for the successful application of DDD:

您的域不平凡

项目组对 OOP/OOD 有经验和兴趣

您可以联系领域专家

您有一个迭代过程

【问题讨论】：

标签： architecture domain-driven-design repository inversion-of-control

【解决方案1】：

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

所以答案是肯定的

【讨论】：

【解决方案2】：

您可能对域模型和 DDD 感到困惑。领域模型是一种架构模式，其中业务实体被实现为 OO 类并利用存储库模式，而 DDD 是一组用于分析和建模业务的流程和原则。 DDD 确实是一种更精细、更正式的领域模型实现方式。

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

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

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

【讨论】：

在这种情况下，将实体层合并到业务层而不是分开（以避免循环引用），将一些业务服务行为移动到域实体中并相互交互是拥有域模型的第一步吗？
我不完全理解您在业务层和实体层之间的区别，但是是的，实体应该包含业务行为。您可能还会混淆位于域之上的应用层，它调用业务逻辑并持久化实体。
例如：（实体层：员工）（业务层：员工服务）。两者都驻留在不同的程序集中，业务层引用实体层，与员工相关的所有逻辑都在 EmployeeService（添加、终止等）中，而实体仅包含基本属性 FirstName 等。

【解决方案3】：

这几乎不是是/否的问题。

业务层的方法是否仅适用于某个类的单个实例？把它移到班级里面。

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

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

【讨论】：