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 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
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.