The companies I consult with are going through an agile DevOps transformation. Typically they focus on transitioning people into teams towards DevOps working, getting groups with max eight people into a team, and being able to work almost autonomously. This transformation almost always poses questions like; How do we divide the current software into the teams, which teams take ownership of what part of the current system, how do we functionally align the teams to the business strategy, and who goes in what team? We call this socio-technical architecture.
To deal with those questions companies request my help to design (micro)services using a Domain-Driven Design approach because it makes it easier to divide the software between teams. I believe enterprises who are going to or doing an Agile DevOps transformation need at least a Domain-Driven Design approach to create autonomous teams that are aligned with the business architecture. Aligning autonomous teams to the business strategy creates a set of unique challenges. In this war story talk, I will share my experience with moving towards autonomous aligned DevOps teams with a Domain-Driven Design approach.
Towards Autonomous Aligned Teams
with Domain-Driven Design
Photo by NASA on Unsplash
“If the architecture of the system
and the architecture of the organization are at odds,
the architecture of the organization wins”
Any organization that designs a system
(deﬁned more broadly here than just information systems)
will inevitably produce a design whose structure
is a copy of the organization's communication structure.
— Mel Conway
Business 1 CRM
[In our study at Thoughtworks we found] work
takes an order of magnitude longer when it
leaves a team.
— James Lewis (@boicy)
Credit: Nick tune
“A loosely coupled software architecture
and org structure to match” is a key
1. Continuous Delivery Performance
2. Ability to scale org and increase
Order Payment Packaging
the key to incremental architecture is to build on
a framework that can accommodate change...
that framework is the domain....
By designing and modeling the domain, you can
more easily handle changes to the domain
— Allen Holub (@allenholub)
To communicate eﬀectively, the code must be based on the
same language used to write the requirements
- the same language that the developers speak
with each other and with domain experts
- Eric Evans
We all know or should know that language is ﬂuid, liquid, subject to the
whims of the people. Language evolves, as it should. Because language
changes to accommodate new users, the older users resist and complain.
Instead of one canonical language,
create multiple bounded languages
It is not the domain experts knowledge
that goes to production, it is the
assumption of the developers
that goes to production
- Alberto Brandolini
A straight line between 2 points
corresponds to a compass direction in
A straight line between 2 points corresponds to
a compass direction in reality..
• Except for points located in Greenland
• Except for points located in Africa
A model is a simpliﬁed representation of a thing
or phenomenon that intentionally emphasizes
certain aspects while ignoring others.
Abstraction with a speciﬁc use in mind.
— Rebecca Wirfs-Brock
Stop communicating business change
in system boundaries
(unit of deployment like in microservices, monolith)
Start communicating business change in
contextual boundaries that form the bounded context
(purpose, need, responsibility)
Domain-Driven Design enables teams to have agency
Agency leads to observability
a necessity for doing progressive delivery
Agile Alliance report:
Domain-Driven Design (DDD) Foundation
Strategic Domain-Driven Design (DDD):
Design Loosely Coupled Architecture
Professional Agile Architecture:
Visual and Collaborative Modelling
15% off training: