9 take-aways from KanDDDinsky Conference

Attending a Domain-Driven Design (DDD) Workshop with Michael Plöd (INNOQ) earlier this year, I got to know the concepts of DDD. It was a hard and abstract topic for me, but I figured that the most important thing is to build a software architecture fitting the individual business needs. That is what DDD focuses on. A bounded context provides us with the solution space and the subdomains containing the problem spaces. To support this, we aim at loose coupling, e.g. not to include external systems in our domain. With the ubiquitous language we make all of this understandable to business people reflecting in an understanding of the domain by the developers.

This makes DDD not only an IT architecture topic. It also touches technical implementation and operations as well as communication and collaboration – ultimately the individual being. That is why KanDDDinsky offered a broad variety on sessions. Be it expressing domain context in an ubiquitous language, using mob programming, continuous delivery to speed up deployment or deliver faster. But read in detail for yourself:

1. DDD supports implementing Datamesh. This means transferring the responsibility of collecting and storing decentralized data to the domain team. This implies that the team can do the related data analysis on their own. It requires them to be future full stack BizDevSecDataOps people (instead of only developers) and having all needed skills within the team or be at least able to grow the skills with the help of the enabling team. Thanks to Jochen Christ for sharing your view on that topic.

2. Don’t aim for an architecture end state. Inherent in a software is its architecture. Software being a living product and therefore subject to change. It means that we cannot aim at ever reaching an end state, neither with software nor system architecture. Aiming for this end state often creates more complexity within the software. We therefore have to accept heterogeneity in our architecture and plan for continuous evolvement or, as Uwe Friedrichsen said in his talk, aim for „road movie“ architecture.

3. Do not start to create a legacy system. Uwe also motivated that, when developing software, you should keep in mind to include data migration possibilities and a removal plan (as well as related documentation). If this is not included in the software, you are creating just another legacy system right from the start. You can never be sure about the impact when shutting down software.

4. Continuous Delivery increases speed, stability and quality. And when we have to decide what to focus on first we should always pick stability in all contexts. Starting with stability ensures speed and quality will follow automatically. This was proven by Thierry de Pauw who took the challenge on getting from bi-annual to fortnightly releases within 4 months for a customer with 15 teams and a single monolith. And this took him only 12 days of his time by the way.

5. Reduce code smell with the help of connascence. Marco Consolaro’s talk “Connascence: beyond Coupling and Cohesion” was focusing on the technical side of building software. He gave code examples about the different stages of connascence and how to reduce the dynamic forms to the static ones. This supports to reduce code smell by transferring to the first two static types of connascence and therefore raises code quality. With the help of knowing the concept of connascence you can refactor your code as you go. Have you been thinking about connascence that is used in your Code?

6. Use Mob Programming or at least Pair Programming! It does not make sense to have each team member work on a separate task. Typing is not the bottleneck when programming. Using Mob Programming raises code quality, increases throughput, reduces review time and fixes code smells right away.

7. Cooperation is in the nature of humans. We always want to cooperate. That is why language was invented in the first place. Avraham Poupko explains that cooperation depends on a shared understanding that itself depends on communication which depends on language. For good collaboration we need unity on the language, on the other hand we need diversity on values and character to solve problems in various ways. A good diversity therefore supports the best solution.

8. Create a friendly conference networking experience. Being a newbie to the DDD Conference setting up a friendly networking environment helped me to get in touch with others. This was enabled by Marco Heimeshoff who set the Pacman rule as a conference guideline meaning when circling up for a discussion always leave space (mouth of pacman) for one more person to join.

9. Use DDD, exchange knowledge and experience. All practitioners at the conference emphasized that using DDD helps business people to design the logic of the software product instead of the developers and should therefore be used when designing any software product.

It was exciting to meet new people, getting a different view on the topic and sharing experiences. I got a lot of new impulses, not strictly related to DDD, but on how to improve my programming practices and get to know more about my domain – which I figured I don‘t seem to know enough about yet.

If you want to browse through the conference sessions, visit the KanDDDinsky webpage and their Youtube channel. For more Information on implementing Domain-Driven Design contact us or get first information on a remote Event Storming by reading this article.