1. Introduction
2. Domain Driven Design elements
In future posts I will show my understanding about the following concepts:
- Layered Architecture
- Services
- Entities
- Value Objects
- Aggregates
- Repositories
- Factories
3. Isolating the domain with a Layered architecture
The design and implementation of business logic constitute the domain layer. Isolating the domain implementation is a prerequisite for domain-driven design.
User interface
- It shows information to the user
- It interprets the user´s commands.
Application Layer
- It defines the jobs the software is supposed to do
- The tasks are meaningful to the business or necessary for interaction with the application layers of other systems.
- This layer is thin and does not contain business rules or knowledge
- It coordinates tasks and delegates work to collaborations of domain objects in the next layer down.
Domain Layer or Model layer
- It represents concepts of the business and the business rules.
- The state that reflects the business situation is controlled and used here
- This layer is the heart of the business software.
Infrastructure Layer
- Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on.
- This infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.
Martin Fowler says: “If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design”.
4. References
Eric Evans 2004. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley.
Posts
I believe that DDD fits much better according to how we "think" about software today. We are not systematic programers, we are high level instead. Of course, there still have a lot to be done till DDD become popular and make people change their mind and concepts. Most developers were "domesticated" and instructed under the Anemic Model and that's what they will always support, that's what their natural instincts says that is correct!! Everyday there are loads and loads of new APIs to help us out. Language is just a pen. If you don't know how to write dosen't matter at all! Think about a class just to transport some information from one layer to another!! A dummy class that helps anything! Why? Give some power to it and transfor into a domain object!.. To sum up, both models are ok.. just like everything else in IT, it depends where you're going to apply it! :)
ReplyDeleteRafa, How would you define "Anemic Model" concept?
ReplyDeleteAnemic Model basically is what everybody does nowadays, value objects everywhere, classes without any "real" representation, that do nothing but transport information, in other words, classes that don't have a "model".
ReplyDeleteAnd I noticed that you like "him" (Martin Fowler) so if you prefer, this pattern was first described by him, as an anti-pattern! where the logic is typically implemented in isolated classes that transform the state of the domain objects.
To whom it may concern: http://www.martinfowler.com/bliki/AnemicDomainModel.html