Domain Driven Design, Software, Team

Software Development – Domain Drive Design

I bought a book about DDD (Domain Driven Design). It’s about this software development methodology. It seems pretty interesting. I’m still at the beginning what I have understood is that developers should work alongside domain experts. This allows developers to distil knowledge from domain information to build a model. This model will be used in software prototyping and/or implementation. This implementation lets refining the model through domain experts’ feedback. The refinement triggers software modification so we can iterate through this process. All the process allows improved models where terminology is always more defined between domain experts and developers that will be used for significant improvements.

Important elements of the process are continuous learning and prototyping/implementations. These allow developers by domain experts’ feedback to validate what they have learned about the domain. On another side they allow domain experts to learn about the rigorous world of software development.

A key principle of DDD is that developers must learn about the domain by working alongside the domain experts that learn about software modelization.

So, what I think, and this is my personal conclusion, is that developers should care about their products and stakeholders. They cannot think to do only technical knowledge acquisition, or get the knowledge of the domain only from the analysts. They cannot ignore the domain. They must have a knowledge of the model as clear as possible.

Lyfestile, Team


There are people that think that developing is a standalone job and every developer should figure out everything on their own. But, from my point of view, these people miss an important part of a developer’s job: teamwork. In fact, when you experience real and inclusive teamwork what you learn is that teamwork is made up of continuous debating that leads to learning a lot from each other every day.

Besides, there are many other aspects we should consider and learn when we come to teamwork:

First, succeeding to be kind is always a good achievement and it’s not easy at all, but human relationships are very important inside teams and the price to pay for a rude contact is to ruin such kinds of relationships. Besides, there are people that say that speaking the truth can ruin relationships, but this is not totally correct. The fact is that it depends on the way you say the truth. Many times, what we lack is the ability to speak and truth (a to be assertive) in a clear and respectful way. Instead often when we come to speak the truth we became nervous and so we appear unrespectful. This is an important skill that should be learned.

Second (but related to the first point), the ability to succeed inside a team lies in the ability to build strong and deep connections and relationships. And in order to reach such a goal, we need to communicate. Speaking could be a good means to communicate but it’s not the only one. What we really need in order to communicate (even though it could seem unrelated) is a sincere desire to contribute to the general wellness of the person, company, community, or institution we want to connect with. And in order to achieve such a goal we need to engage in a personal development path.

At last but not least, surely teams where we land are not perfect, surely they could have a lot of flames but we should think we’re not helpless. We can give a great contribution to improving the team. I know, it’s not easy but what a team needs is dreamers and people with purpose, and if you are one of them even though you could encounter a lot of issues (they could be fixed with patience, humility, and kindness) you will succeed. On the rest, every single step, even if the smallest, is however a step towards improvement.

However, we should keep in mind, that if the team doesn’t fit with us, we could leave and find another team that better fits with us. We should have always cleared our purpose and checked them against the team’s purpose but this doesn’t mean we shouldn’t give our contribution to the team we are now.

Teams are made of people, and people are, in the last instance, what we should care about.