GuideBeginner
Architectural Styles And Boundaries
Learn to structure a system from the inside: how to split it into parts, where to draw the boundaries, and which style — monolith, modular monolith, microservices — fits which context. The guide's core is coupling and cohesion, and lightweight Domain-Driven Design bounded contexts: group what changes together, separate what changes for different reasons. You work through a single case study from start to finish: Mercado, a marketplace that started as a boundary-less monolith where everything touches everything (a change in Reviews breaks Checkout), which you'll restructure by drawing its five bounded contexts (Catalog, Orders, Payments, Shipping, Reviews). Every coupling metric — fan-in/fan-out, instability, blast radius, cycle detection — is calculated and executed in Python over a real dependency graph, never quoted from memory. The guide closes with a capstone that restructures Mercado's whole monolith: a context map, a justified style decision, and metrics measured before and after.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Distinguish coupling from cohesion and understand why code structure decides the cost of change
- Draw bounded contexts with lightweight DDD: spot where the same business concept means different things in different contexts
- Build a modular monolith with hard internal boundaries, without needing microservices
- Judge what you gain and what you pay when moving to microservices (independent deployment vs. network calls, distributed consistency, observability)
- Decide whether communication across a boundary should be synchronous (REST/gRPC) or asynchronous (events), as a coupling decision
- Apply decomposition strategies by business capability, including the strangler fig pattern to extract services gradually without breaking everything
- Measure and defend a boundary with real coupling metrics (fan-in/fan-out, instability, blast radius) and fitness functions that fail when someone crosses it
- Restructure a real monolith end to end: a bounded-context map, a style choice, cross-boundary communication, and before/after metrics
Before you start
What you need to bring
It's for you if...
- Backend devs working in a monolith that "hurts" and need a criterion, not a trend, to decide what to extract
- Devs and tech leads evaluating whether moving to microservices actually solves their problem or just relocates it
- Anyone who wants to apply DDD bounded contexts without doing the full strategic process
- Teams that need to defend an architecture decision with measurable metrics, not opinions
Requirements and materials
- Basic Python (to run the coupling metrics over dependency graphs)
- Having worked on a backend with several modules or services, even a simple monolith
- No prior experience with microservices or Domain-Driven Design required
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: from the forces to the boundary
- 2. What a bounded context is
- 3. The five bounded contexts of Mercado
- 4. Ubiquitous language per context
- 5. The same concept means different things
- 6. The boundary as a contract
- 7. Signals for where the boundary goes
- 8. Mini-project: map the bounded contexts of Mercado
- 1. Module introduction: Mercado without microservices
- 2. What a modular monolith is
- 3. A module with a public interface
- 4. Forbidding imports of internals
- 5. From ball of mud to modular in Mercado
- 6. Transactions and simplicity in one process
- 7. When modular is enough (and you don't need microservices)
- 8. Project: modularize a Mercado module
- 1. Module introduction: the bill almost nobody reads
- 2. What a microservice is (and is NOT)
- 3. What you gain: four independences
- 4. The cost of the network, executed
- 5. Distributed consistency without ACID
- 6. Observability and distributed debugging
- 7. When YES and when NO
- 8. Project: extract a context and justify the cost
- 1. Module introduction: how the two sides of a boundary talk
- 2. Synchronous vs asynchronous communication
- 3. Temporal coupling: the price of waiting
- 4. The event as decoupler
- 5. Orchestration vs choreography
- 6. The boundary as a versionable contract
- 7. Choosing synchronous or asynchronous at each Mercado boundary
- 8. Project: define the communication style of each Mercado boundary
- 1. Module introduction: measuring and defending boundaries
- 2. Why measure boundaries
- 3. Fan-in, fan-out and the coupling metrics
- 4. Instability and the Stable Dependencies Principle
- 5. Detecting cycles between modules
- 6. Fitness functions and architecture tests
- 7. Conway's Law and the team↔boundary map
- 8. Project: measure and defend Mercado's boundaries
- 1. Module introduction: the trip back down
- 2. Step 1: draw Mercado's context map
- 3. Step 2: choose the style (modular monolith first)
- 4. Step 3: what to extract first, with the strangler fig
- 5. Step 4: define the communication of each boundary
- 6. Step 5: measure the coupling, before and after
- 7. The decision record: gather the five pieces
- 8. Project: restructure Mercado (final deliverable)
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!