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

Question

我有一个项目，我已经在开发传统的3层架构（实体/业务/用户界面），我正在应用存储库模式和IoC。

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

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

[编辑] 假设这是最好的事情，请：

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

    

  （避免循环引用，因为实体可以有行为甚至   在我的理解中致电商业服务）

• 将部分业务服务行为移至域实体中是否是拥有域模型的第一步？

[详细]

http://en.wikipedia.org/wiki/Domain-driven_design

  

Prerequisites for the successful application of DDD:

     

  
• 您的域名并非无足轻重
  
• 项目团队对OOP / OOD
有经验和兴趣   
• 您可以访问域专家
  
• 你有一个迭代过程
  

Answer 1

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

所以答案是肯定的

Answer 2

您可能会对域模型和DDD感到困惑。域模型是一种体系结构模式，其中业务实体实现为OO类并使用存储库模式，而DDD是一组用于分析和建模业务的过程和原则。 DDD实际上是一种更加精炼和正式的域模型实现方式。

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

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

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

Answer 3

这几乎是/没有问题。

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

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

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