The Greenbox Story · Series
Drawing the Lines
Creating the technical structure to scale — bounded contexts, decision tables, and architecture decision records.
The Greenbox Story · Drawing the Lines
Domain-Driven Design: Drawing the Boundaries
The codebase is becoming a monolith. Charlotte helps the team define bounded contexts so the architecture matches the business, and so LLMs generate code that fits.
Read article
The Greenbox Story · Drawing the Lines
Domain-Driven Design: Modelling the Subscription Context in Go
Charlotte said draw the boundaries. Tom said fine. Now someone has to write the code. This is what DDD looks like in Go, value objects, entities, aggregates, and the type system doing half the work.
Read article
The Greenbox Story · Drawing the Lines
Domain-Driven Design: Events Across Boundaries in Go
Bounded contexts don't help if they can't talk to each other. Domain events are how the Subscription context tells Billing that something happened, without knowing Billing exists.
Read article
The Greenbox Story · Drawing the Lines
Domain-Driven Design: The Anti-Corruption Layer in Go
When one context needs to talk to another, the temptation is to import its types. The anti-corruption layer says no, translate at the boundary, and let each context own its own language.
Read article
The Greenbox Story · Drawing the Lines
Drawing the System: From Event Storm to C4
The wall told the team where the boundaries were. But the wall lives in one room, and the team doesn't. Charlotte introduces C4, the diagrams that let anyone who wasn't in the room understand what Greenbox actually is.
Read article
The Greenbox Story · Drawing the Lines
Decision Tables: Making Maya's Brain Explicit
The substitution rules Maya carries in her head now need to be captured for the new team. Decision tables express complex multi-condition logic that LLMs can implement comprehensively.
Read article
The Greenbox Story · Drawing the Lines
Decision Tables: The Substitution Engine in Go
Maya's substitution rules are captured in decision tables. The LLM generated a thousand lines of Go and four hundred tests from them. This is what that code actually looks like.
Read article
The Greenbox Story · Drawing the Lines
Architecture Decision Records: Why We Did It That Way
With LLMs writing more code and new people joining the team, nobody can explain why things are the way they are. Charlotte introduces ADRs, the institutional memory the codebase desperately needs.
Read article
The Greenbox Story · Drawing the Lines
Domain-Driven Design: Event Sourcing the Ledger in Go
Charlotte said the DDD refactor needed no event sourcing. She was right. Then a subscriber asked why she was charged during a pause, and the ledger could only show the balance, not the story behind it. Most contexts care what is. The ledger has to remember what happened.
Read article
The Greenbox Story · Drawing the Lines
Domain-Driven Design: CQRS and Read Models in Go
The event-sourced ledger can explain any single account. Then Maya asks for the dashboard (every subscriber in arrears, this week's revenue, the failed charges) and you cannot replay every account to draw a table. The model you write through and the model you read from want to be two different things.
Read article