20201109 - FlowConFR2020 - Defining Socio-Technical Boundaries with the Bounded Context Canvas, Nick Tune

by Thierry de Pauw on

#flowcon

Defining Socio-Technical Boundaries with the Bounded Context Canvas, Nick Tune, @ntcoding

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

  • @cgodard: "Just making things smaller (ex: microservice architecture) doesn't lead to good design" @ntcoding #FlowCon https://t.co/fIDFYwLrkM

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

How to find good socio-technical boundaries?

  • Software Development teams: the system of work
  • The Market: the system of value exchange
  • Software Architecture: the system of software

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

Domain Architecture

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

Introducing the Bounded Context Canvas

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

  • inbound communication
  • outbound communication
    global complexity: how big is this interface, number of collaborators to interact with

  • ubiquituous language

  • 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

Domain-Driven Design starter modelling process

  1. align: to business model (business model canvas)
  2. discover: event storming
  3. decompose
  4. connect
  5. bounded context heuristics
  6. challenge how systems talk to each other
  7. isolate the core domain(s) => bounded contexts

Building the Canvas

What's your name?
=> 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?
=> description

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

Strategic Classification

domain:
- core:
- supporting: enable the core domain
- generic: things you see in other domains eg identity services, payment services

business model:
- is it revenue?
- is it engagement?
- is it about compliance?
- it it to reduce cost?

evolution: Wardley mapping
- genesis
- custom built
- product
- commodity

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

  • Naming: cohesiveness, do all of these words make sense together
  • Message Type
  • ...

Collaborators:
- bounded context
- external system
- frontend
- direct user interaction
=> collaborators are dependencies towards other teams!

too many collaborators => too many dependencies

tips for critiquing Collaborators:
- number of collaborators
- chattiness
- ...

Context Mapping => Team Topologies

Business Decisions
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

Ubuiquitous Language

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

Domain Roles
some bounded contexts are about specifications
other bounded contexts keep a record

  • draft context
  • execution context
  • analysis context
  • gateway context
  • other

more roles may indicate too much local complexity

A recipe for making good boundaries

  • understand the business model
  • explore your domain
  • identify architectural options
  • assess local vs global complexity
  • assess the org impact, what is the social impact
  • place your bets ... and continuously monitor them