CHAPTER 1- What is Domain-Driven Design?
When we start developing a product, we ought to concentrate on the space it is working in. The whole motivation behind the product is to improve a particular domain. To have the capacity to do that, the product needs to fit congruously with the area it has been made for. Else it will bring strain into the area, inciting glitch, harm, and even wreak mayhem.
So we begin with a domain. As per Eric Evans, a domain model is not a specific outline but a thought to be passed on. The model is our interior portrayal of the objective area, what's more, it is extremely important all through the plan and the advancement prepare. We have to discuss this model with domain experts, domain analyst, and with software engineers. We have to make ways to express it, to discuss it with others.
There are different approaches to express a domain.
One is graphical: Charts, use cases, drawings, pictures, and so forth. Another is writing it down. We record our vision about the domain. We can make a language to convey particular issues about the domain, this should be possible by utilizing Ubiquitious Languag.
There are different approaches to head towards software design.
Waterfall design method:
Business expert->Business analyst->Software developers
This strategy includes various stages. The domain experts set up an arrangement of prerequisites which are imparted to the domain analysts. The domain analysts make a model depending on those prerequisites, and pass the outcomes to the software developers, who begin coding in light of what they have received.
The main issue with the traditional Waterfall design methodology is that there is no feedback from the domain analyst to the domain experts or from the developers to the analysts.
Agile methodologies such as Extreme Programming:
These strategies are a system developments against the Waterfall approach, result of the challenges to cope up with the necessities, especially when necessities get changed very often. It's truly difficult to make a total model which covers all parts of a area at once. While Agile advocates perceive the significance of Design decision, they oppose upfront design. Agile Methodologies utilize a lot of implementation adaptability, through iterative development with persistent business skateholders interest and a considerable measure of refactoring. The team of Software developers gets the opportunity to learn more about the client domain hence can better create software products that meets the clients requirements.
The problem with Agile Methodologies is the persistent refactoring done by developers without strong design standards will deliver code that is difficult to understand and changed further. Waterfall approach may prompt to over-designing, while the Agile approach may prompt to another threat which is doing a deep design strategies.
Principles of Domain-Driven Design:
- Domain Driven Design can incredibly expand any development process' capacity to model and execute the complex issues in the domain in a practical way.
- It demonstrates how Design and Development can operate together to make better solutions.
- Great Design plan will quicken the development, while input originating from the development procedure will improve the Design Plan or Strategies.
Developing Domain Model by building Domain Knowledge:
Lets take an example of a Unmanned Vehicle System.
The proposed project is a Unmanned Vehicle System which determines how the software components should be identified and organized, checks if the car follows its supposed route or not, and if there is the possibility of a collision.
Automotive designers are the specialists of this domain or domain experts. The domain expert and you agree that each car has a departure and a destination system. So we have a car, a departure and a destination. The domain analysts absorbs these informations and creates a domain model accordingly. This domain model is passed to the developers. The developers might think that instead of associating car with destination and departure it can be associated with a specified route. Then we might discover that a route is made up of small segments. In this way, a route can be considered as a progression of back to back fixes. Now we no longer observe the destination and departure as the main terms of the route, but simply one more two of those fixes. This is most likely very different in relation to how the Automotive Designers sees them. However it is a vital reflection which helps later. This may appear like an extremely time consuming procedure, and it is, however this is the way it ought to be, since at last the product's motivation is to understand business issues in a specified domain area, so it needs to mix perfectly with the domain.
Communication between domain experts->software architects->software developers are vital when developing a domain model.
Important Chapters in Domain Driven Design
