Domain Driven Design - Key Benefits - DDD

Domain Driven Design is a software methodology appropriate for a particular type of application where there is significant complexity and has an important focus of a business model well defined.

DDD is a disciplined way to create a Domain Model, that's all. The focus of the technique is to create a domain that speaks the user language.

Key Points:

• Common language between developer and business person.
• Precise communication.
• Provides a business view to the developer, spreads knowledge between the team.
• Eric Evan recommends a layered architecture with: Presentation, Application, Domain, and Infrastructure.
• The purpose of Domain Driven Design is to create better software, focusing on a domain model, rather than the technology.
• The software is guided by domain and not by the UI.
• DDD is a way to make them more manageable complex systems, better understands avoiding a classic ball of mud.
• Experiment a lot and expect to make lots of mistakes. Modeling is a creative process.

Keep in mind some of the pitfalls of domain modeling:

• Domain work is difficult and requires a lot of knowledge not necessarily related technical skills.
• Domain modeling requires knowledge processing the business.
• Developers tend to create models with concepts that seem superficial to domain experts.
• It requires an iterative development process and continuous refactoring. This is hard for some companies and can become expensive.
• DDD cannot help or don't bring benefit if the software is very generic.
• Bad nomenclatures can harm the DDD.
• Lack of domain is one of the main reasons for the DDD fail.
• Lack of core domain helps to fail in the implementation of DDD.
• Framework and Library can confuse the implementation of DDD.
• It is necessary to have an implementation strategy (Design, Boundaries).
• Don't try to apply DDD to everything. Draw a context map and decide on where you will make a push for DDD and where you will not. And then don't worry about it outside those boundaries.
• Focus on specific scenarios. Abstract thought has to be agreed in individual cases.

DDD is not a silver bullet for all application development, it only helps manage complexity, where the complexity comes from the domain.

It all comes down to the complexity of the behavior in your system. If you have complicated and ever-changing business rules involving validation, calculations, and derivations you’ll want an object model.

Erick Evans Sentences:

• A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving problem at hand and ignores extraneous detail.
• A domain model is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge
• We need to decouple the domain object from other functions of the system, so we can avoid confusing the domain concepts with other concepts
• The domain layer is the heart of the software and this is where the interesting stuff happens
• In DDD, we don’t consider any databases.
• DDD is all about the domain, not about the database, and Persistence Ignorance is a very important aspect of DDD

All that I  put here in this post are some phases, some conclusions, some links that I used in my studies about DDD. 

References and Interesting links:

• http://www.infoq.com/articles/eric-evans-ddd-matters-toda 
• http://www.markhneedham.com/blog/2008/09/19/should-we-always-use-domain-mode/ 
• http://blog.fragmental.com.br/2007/06/22/cuidado-com-domain-driven-design/
• http://thinkbeforecoding.com/post/2009/06/17/When-DDD-should-be-considered
• http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
• http://pt.slideshare.net/azborgonovo/introducao-ao-domain-driven-design
• http://www.cqrs.nu/Faq/domain-driven-design
• https://lostechies.com/gabrielschenker/2015/04/28/ddd-applied/
• https://lostechies.com/gabrielschenker/2015/05/25/ddd-the-aggregate
• http://www.infoq.com/presentations/ddd-imperfect-design
• https://lostechies.com/gabrielschenker/2015/04/16/ddd-revisited/
• http://www.easel.ly/auth/login
• http://pt.slideshare.net/_leopro_/clean-architecture-with-ddd-layering-in-php-35793127