Domain Driven Design
- The idea of domain driven design is to capture all requirements in our model and can’t assign ad hoc responsibilities to domain classes. This comes with domain layer in layered architecture. Here we don’t concern infrastructure details and technology. We only need to concern about object oriented concepts. That means capture the concepts and represent those concepts in object oriented manner, like classes, objects etc… Normally these are commonly known things. However design should be nice and usable, because it becomes the foundation for rest of other process.
- If the existing design cannot be afforded by using existing technology, it should flexible to change technology to achieve the design. It should not keep two designs for analysis & design and implementation. That should be same. So it can map one to one between design model and implementation model. When it is using only one design there should be a feed back loop through out the life cycle
- Language can use different words to express same thing and can use one word to represent two things. These are wrong. Better way is to represent one word for one thing. Then we can reduce conflicts and provide more meaningful language.
- Services are not part of the domain, but need to carry out the domain. Actually services capture responsibilities and system requirements. One of the best practice is one class should have only one responsibility. As an example consider the university domain and its parts like library, canteen, bookshop, examination department. All of these are services and library, canteen, bookshop are infrastructure services. So university domain can exist without this domain. But the service like examination department is domain services, means these are mandatory service for university domain. It can’t exist without that domain services.
- We can use modules to reduce complexity. It’s very important to increase cohesion and reduce coupling. It’s important to remove dependencies between modules and provide the ability to work independently. There can be tight coupling within module and reduce the coupling among modules. As an example consider a DVD player and amplifier. Here there are many open jacks to connect other sub systems but no way to change interior of particular sub system. Also these modules should reflect domain concepts.
- Every aggregate has a boundary. It can be divided into normal aggregates and root aggregates. Root aggregate is the owner of other classes. In the example we are discussed customer is the root aggregate. Contact info and address can’t change without knowing the customer. That means customer has full control of these two.
- Object creation and assign something to object is two different things. As an example construct car and use car is two different things. Factories responsible for create objects. If we want to do a particular job we need to call objects. Repositories like directory. Those are help to find objects inside the memory. These repositories hide implementation details, means encapsulation is there. Here we don’t need to concern where the object is and only need to refer matching criteria.
S.R.S. Gunawardana - 044012