我有一个项目，我已经在传统的三层架构(实体/业务/UI)上工作，并且我正在应用存储库模式和IoC。
这里的想法是，我们是业务所有者，但业务正在发展，不能说实际上有一个最终的领域，准备实施。我的实体不包含复杂的业务，我将业务逻辑保留在业务层。
虽然我们已经在使用存储库模式和IoC，但迁移到DDD是否真的有额外的价值，我应该将业务合并到实体中吗?
[Edit]假设这是最好的做法，我会:
-
将实体层合并到业务层，而不是分开
(避免循环引用，因为实体可以有行为，甚至呼叫业务服务在我的理解)
-
将一些业务服务行为移动到适用的域实体中是拥有域模型的第一步吗?
http://en.wikipedia.org/wiki/Domain-driven_design
DDD成功应用的先决条件:
- 您的域名不是微不足道的
- 项目团队对OOP/OOD有经验和兴趣
- 您可以访问域专家
- 你有一个迭代过程
DDD的主要思想不仅仅是使用存储库，它与IoC无关，它是关于拥有一种业务通用语言，并根据反映业务的实体和值对象来设计您的领域层，这样您就需要以面向对象的方式对其进行真正的建模，其中对象封装数据并包含行为。这样，应用程序在业务逻辑方面更易于维护，并且可以通过使用面向对象的技术(如抽象、多态性、组合等)进行扩展。
所以答案是肯定的
您可能会对领域模型和DDD感到困惑。领域模型是一种体系结构模式，其中业务实体被实现为OO类，并利用存储库模式，而DDD是一组用于分析和建模业务的流程和原则。DDD实际上是实现领域模型的一种更精细和正式的方式。
无论如何，您不应该需要一个"最终"one_answers"准备实现"的域，因为域模型和DDD都是为不断发展的域模型设计的。
您说业务层包含逻辑而不包含实体，而实际上实体是业务层(或域)。
我想说，实现领域模型的开销是最小的，从长期来看，对于一个不断发展的模型来说，几乎总是值得的。
这不是一个是非问题。
从业务层的方法只与一些类的单个实例工作吗?把它移到类中。
它是否适用于集合，几个不同的类和/或逻辑更复杂?可能没有一个通用的答案，无论你做什么决定，都不要引入循环依赖关系，并试图破坏现有的依赖关系——当需要进行重构时，你迟早会感激的。
完成后，检查API并尽可能地从中删除。