One of the purposes of the year 2020 was to deepen the DDD approach and hexagonal architecture using my favorite framework (Symfony) as a starting point. I have already mentioned some of the ideas that I extracted in the symfony course that you have available on my YouTube channel.
Today I begin a series of articles in which I will shape all the notes I took over the past year with the aim of bringing you a little closer to the fundamental ideas on which DDD is based.
Will you accompany me?
What is DDD?
The idea of the DDD approach (acronym for Domain — Driven — Design) is very simple: align all the teams involved in the development of a product:
- Achieve fluid and two-way communication between the business team and the development team.
- Ensure that the developed product meets business expectations.
- Facilitate the iterability and maintainability of the product.
This is why “ubiquitous language” is so important in DDD. Defining it at the beginning of the development of a long-range product is what will allow software and business to work under the same domain of ideas.
A “silly” example in the development of a blog: the ubiquitous language will help us to prevent the business part from talking about “articles” while the software has entities called “posts”.
Is DDD “a silver bullet”?
No, DDD is not always the optimal solution — this approach takes a lot more time and more involvement from the entire team than normal development. In addition, transferring the business domain to software requires following certain standards that allow those ideas to be ported to the entities and services of the application. Stick with this idea:
DDD encourages us to bring business logic as close as possible to our domain entities.
Therefore, before launching to implement a project with a domain-based approach, make sure that you have the appropriate time and involvement.