by Thierry de Pauw on
Good socio-technical architecture improves organisational performance, @ntcoding
research: why is socio-technical architecture useful?
"A loosely coupled software architecture and org structure to match" is a key predictor of:
- Continuous Delivery performance
- ability to scale org and increase performance linearly
Architecture hasn't really been at the forefront of Continuous Delivery in the past, although it is really key for organisational performance!
[In our study at ThoughtWorks we found] work takes an order of magnitude longer when it leaves a team
-- James Lewes, @boicy
science suggest that when we have a loosely coupled architecture and team we can perform better as organisation, @ntcoding
Just making things smaller - "micro", "2 piza" - doesn't lead to good design. @ntcoding
Balancing local vs global complexity
Why a flat organizational structure will Fail as you Grow?
3 people, 3 lines of communication paths
4 people, 6 lines
5 people, 10 lines
6 people, 15 lines
The architecture of the org will be aligned with the software arch, Conway's Law
The Market is part of the Domain
We need to define the arch of the domain in an optimal way, fit the team into that architecture.
=> start with the domain
Choosing for autonomous teams is a good decision, but not enough!
Domain boundaries are designed not discovered ...
How to group domain concepts in your micro-services architecture?
=> taxonomies, topologies
=> this is what domain modelling is about, there is no single right model
How to choose the right boundaries?
watch your business model
=> Business Model Canvas
when you look at business models there are numerous numbers of business models
How to minimise coupling?
look at cohesive domain: what changes together
language and carve out bounded contexts
that is the essence of DDD: look at your domain, look at your domain boundaries
Socio-Technical boundaries are bets ... about how the system will evolve in the future.
we are guessing on how things will evolve over time because we don't know the future
The Bounded Context Canvas is a tool for capturing all of the relevant information so you can make informed bets.
@tdpauw: Bounded Context Canvas by @ntcoding #flowcon https://t.co/zM4UEs2Kd7
Description: what is the purpose, what business decision does it serve
bounded context = microservice
global complexity: how big is this interface, number of collaborators to interact with
business decisions: local complexity, how big are the business rules
Available on GitHub: https://github.com/ddd-crew/bounded-context-canvas
Miro Template available
software solution: Softwarepark/Contexture : https://github.com/Softwarepark/Contexture
What's your name?
often one of the most useful part of the canvas
naming things is hard, people tend to use generic names like eg management, they don't make it clear what is inside or outside, @ntcoding
register is a better name: it says what does not belong here
Tell us about yourself?
forces a team to agree in writing, can take a while and involve people getting upset with each other
whenever you find "and" in the description it informs us there might be a bounded context in here and you need to split it @ntcoding
- supporting: enable the core domain
- generic: things you see in other domains eg identity services, payment services
- is it revenue?
- is it engagement?
- is it about compliance?
- it it to reduce cost?
evolution: Wardley mapping
- custom built
Wardley Mapping the future
=> thinking over how your architecture will evolve over time
eg we can't buy this off the shelf at this time but we think it might be available in 2 years => let's custom build
eg our core domain becomes a commodity, we should buy it off the shelf
Bounded Context Interface
- query: asks for information
- command: executes something
- event: an notification that something happened
=> Inbound and Outbound communication + Ubiquitous Language and Business Decisions
tips for critiquing a Context's Interface
- bounded context
- external system
- direct user interaction
=> collaborators are dependencies towards other teams!
too many collaborators => too many dependencies
tips for critiquing Collaborators:
- number of collaborators
Context Mapping => Team Topologies
the key business rules, policies and decisions
=> how complex is this going to be locally
who cares about the results of these decisions?
Decision Types: different kinds of rules
strict decisions: can't be changed afterwards
some rules can't be enforced all the time, you need compensating rules to apply afterwards, eg bank accounts can't go negative
what are the key domain phrases everybody should know about?
what is the precise meaning of key domain concepts? eg my tomato is not necessarily your tomato
some bounded contexts are about specifications
other bounded contexts keep a record
more roles may indicate too much local complexity