Conway’s Law – From TDD to DDD

Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” (wikipedia)

“Test Driven Development” (TDD) is a crucial cornerstone if the organization wants to realize CI/CD and be truly “agile”. See this post about TDD for more… However reality looks different: At the 2022 DSAG “Technologietage” the talk about “ABAP Unit” gives interesting insight – TDD is barely used: LINK tbd.

DSAG continuously pushes this topic – and recently hosted a 1-hour session about DDD – Domain Driven Design. What’s that, and how is it connected to TDD?
The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns. The problem, which DDD tackles are “communication boundaries” between the business and IT, as well as mitigating design decisions, which are made without the Dev-Team. The common focus on “documents instead of collaboration”, “stille Post” and the fact, that every stakeholder has a own “mental model” of the requirements makes communication, collaboration and output-oriented work difficult. So while TDD is on the technical side, DDD resides on the cultural and “soft skill” side – aiming at building a socio-technical architecture. The basic idea of DDD is:

– every business domain is unique and requires knowledge – one must acknowledge that.
– therefore, use “one” language (Domain/Business & Developer) to reduce the distance between problem and solution.
– “share” one domain-model
– divide & conquer

Disclaimer: DDD sounds super-interesting, but i’m also still in the learning stage – so bear with me.

Phases (ddd-starter):
1) Understand
2) Discover
3) Decompose
4) Strategize
5) Connect
6) Organize
7) Define
8) Code

What does this mean in detail for the day-to-day work? What are the central patterns:
– Ubiquitous Language
using a common language (
– Bounded Context
divide & conquer: divide large scopes and systems into “different Bounded Contexts and being explicit about their interrelationships.” (
(1) Understand: Business Model Canvas and User Story Mapping to understand the business domain (ddd-crew: Starter – understand). Used both several times – still don’t grasp the domain? Try…
– Event Storming
Never did this, but sounds interesting: ddd-crew: Event Storming to continuously (!) (2) discover the domain visually and collaboratively (ddd-crew: Starter – discover). See:
– Context Mapping
(3) Decompose: “Context Maps describe the contact between bounded contexts and teams with a collection of patterns.” My favorite one is “Big Ball Of Mud” – which sounds way to familiar: “A (part of a) system which is a mess by having mixed models and inconsistent boundaries.” (ddd-crew)

– DSAG Technolgietage 2022 – Unit tests (tbd)

Eric Evans – Getting Started with DDD When Surrounded by Legacy Systems
Coffee Corner Radio – Episode-60 – Architectural-Patterns-Discussion-with-Eberhard-Wolff

Amazon: Eric J. Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.