Conway’s Law – From TDD to DDD
“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 (martinfowler.com)
– Bounded Context
divide & conquer: divide large scopes and systems into “different Bounded Contexts and being explicit about their interrelationships.” (martinfowler.com)
– (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: https://www.eventstorming.com/
– 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)
Resources:
– DSAG Technolgietage 2022 – Unit tests (tbd)
– martinfowler.com/
– https://github.com/SAP/curated-resources-for-domain-driven-design
– https://github.com/ddd-crew/welcome-to-ddd
– https://github.com/ddd-crew/context-mapping
– https://github.com/ddd-crew/ddd-starter-modelling-process
– https://www.dddcommunity.org/
– https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf
Media:
Eric Evans – Getting Started with DDD When Surrounded by Legacy Systems
Coffee Corner Radio – Episode-60 – Architectural-Patterns-Discussion-with-Eberhard-Wolff
Books:
Amazon: Eric J. Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software
