Evolving Business - DDD or Not?

I have a project where I'm already working on a traditional 3 layers architecture (Entity / Business / UI), and I'm applying the repository pattern and IoC.

The idea here is that we are the business owners yet the business is evolving and cannot say there is actually a domain final and ready to be 开发者_Python百科implemented. My entities do not contain complex business and I'm keeping my business logic in the business layer.

Is there really an extra value from moving to DDD although we are already making use of the repository pattern and IoC, should I incorporate my business into my entities?

[Edit] Assuming it is the best thing to do, would:

• Merging the entity layer into the business layer rather than being separate

  (to avoid cyclic references since entities can have behavior and even call business services in my understanding)

• Moving some of the business services behavior into the domain entities where applicable be the first step to have a domain model?

[More]

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

Prerequisites for the successful application of DDD:

• Your domain is not trivial
• The project team has experience and interest in OOP/OOD
• You have access to domain experts
• You have an iterative process

The main idea of DDD is not to just use the repository, and it has nothing to do with IoC, it is about having a business ubiquitous language, and design your domain layer in terms of entities and value objects reflecting your business, this way you need to really model it in an object oriented way where objects encapsulates data and include behavior, this way the application will be more maintainable in terms of business logic and will be extensible by utilizing object oriented techniques like abstraction, polymorphism, composition, ...

So the answer would be yes

You may be getting confused between Domain Model and DDD. Domain Model is an architectural pattern in which business entities are implemented as OO classes and which utilises the repository pattern, whereas DDD is a set of processes and principles for analysing and modelling the business. DDD is really a more refined and formal way of implementing Domain Model.

Anyhow, you should not need a domain that is 'final' and 'ready to be implemented' as both Domain Model and DDD are designed for an evolving domain model.

You say that the business layer contains the logic and not the entities, when in fact the entities ARE the business layer (or Domain).

I would say the overhead in implementing Domain Model is minimal, and almost always worth it in the long term with an evolving model.

This is hardly yes/no question.

Does a method from business layer work only with a single instance of some class ? Move it inside the class.

Does it work with collection(s), several different classes and/or the logic is more complex ? There is probably no universal answer, whatever you decide do not introduce circular dependencies and try to break existing ones - sooner or later you'll be grateful for that when some refactoring is necessary.

After you're done, inspect API and remove from it as much as possible.