Domain Driven DesignThe term "Domain Driven Design" was coined by Eric Evans in 2003 in his book titled "Domain Driven Design".
The Domain Driven Design (DDD) is an approach to software design which makes us focus on the heart of the application i.e. complexity of the business domain rather than technical details. DDD contains a set of patterns for building enterprise applications from the domain model out.
Advantages of DDDHere are the advantages of using Domain Driven Design:
i) PatternsDDD gives us the principles and patterns to solve difficult problems in software as well as sometimes in business. These patterns have been successfully used to solve complex problems.
ii) History of SuccessIt has a history of success with complex projects. It aligns very well with the experience of developers and successful software applications already built.
iii) Clear CodeIt helps us write clear and testable code that represents the domain. The code is more focused and concise
iv) Better UnderstandingIt helps us understand client needs better.
What It InvolvesTo look at the Domain Driven Design from a high level, here are a few critical pieces which are important for us to successfully follow DDD methodologies:
i) Interaction with Domain ExpertsThere is a lot of back and forth interaction with Domain Experts. The communication between the developers and domain experts is critical to the success of this methodology and our software. We as developers need to understand their terminologies, how they want to use the system and their pain points.
ii) Focus on part of DomainSince the domain is complex, we need to divide it into sub-domains. By doing this, we are keeping the conversation focused to a specific sub-domain at a time. This leads to better understanding on both sides.
iii) Focus on part of Domain (again;)During development too, the focus is on one sub-domain at a time. It helps the modeling and implementing of sub-domain efficiently and directly ties into separation of concerns principles.
Advantages of DDD to CodeIf we follow Domain Driven Design, the resultant code also has a few advantages:
i) SuppleBy following DDD, the code is very flexible and will be easier to change and extend.
ii) Solving Customer ProblemThe resultant code is generally much more close to customer's vision and perspective of the problem.
iii) Divide and ConquerSince we are breaking the complex problem into smaller pieces, the resultant code is also easier to write and read. It is much better organized and it should have fewer issues and should be easier to test.
iv) Patterns to LeverageEven if we don't use DDD by the word, it still helps us to see many great patterns to leverage.
Disadvantages of DDDDDD comes with a lot of advantages. However, there are a few disadvantages as well:
i) Only if Domain is ComplexThe real benefit of DDD shows up only if the domain is complex. If the domain is simple, then DDD might be an overkill.
ii) Time Consuming UpfrontThe developers have to spend a lot of time with domain experts to understand the domain thoroughly. This can be time consuming on both ends. Also, deciding the sub domains and system boundaries can also take lot of time.
iii) High Learning CurveDDD has a high learning curve initially. Getting used to this new way of thinking might be painful at first but I think we as developers do like to give ourselves pain :P
ConclusionDomain Driven Design helps us focus on the client problem and guides us in the direction of solving it using divide and conquer technique. We will be delving deeper into DDD in subsequent blog posts.
Domain Driven Design book By Eric Evans