Review Glossary FR

Size

Eyes

Finish a part in any dojo to unlock the next eyes.

Become an architect, ten minutes a day.

One chapter a day, on real open-source code. Questions you get right come back 1, 3, 7, 21 and 45 days later.

Today · day 1 · 10 min

Software architecture: the decisions that are expensive to change
Start reading →

0 of 40 chapters done

Thinking like an architect: 0 of 5Seeing the system: 0 of 4Inside a service: 0 of 4Between services: 0 of 6Domains and boundaries: 0 of 3The pattern toolbox: 0 of 8The architect's job: 0 of 5Built to last: 0 of 5
One pillar per part. It fills as you finish its chapters.

The path

Thinking like an architect: 0 of 5Thinking like an architect

  1. Software architecture: the decisions that are expensive to change 1
  2. Architecture characteristics: choosing the top three 2
  3. Quality scenarios: making "secure" testable 3
  4. Architecture decision records: writing down the why 4
  5. Reversible decisions: one-way and two-way doors 5

Seeing the system: 0 of 4Seeing the system

  1. The context diagram: your system as one box 6
  2. Containers: what actually runs 7
  3. Following one request end to end 8
  4. Deployment: boxes on machines 9

Inside a service: 0 of 4Inside a service

  1. Layers: imports only go one way 10
  2. Ports and adapters: one core, many backends 11
  3. Coupling and cohesion in a checkout service 12
  4. Multi-tenancy: whose data is this? 13

Between services: 0 of 6Between services

  1. Sync calls vs async jobs 14
  2. Failure: timeouts, retries, idempotency 15
  3. Consistency across several stores 16
  4. Who owns the data 17
  5. Gateways, tokens and SSO 18
  6. Caching 19

Domains and boundaries: 0 of 3Domains and boundaries

  1. Core, supporting and generic subdomains 20
  2. Bounded contexts and context maps 21
  3. Architecture styles 22

The pattern toolbox: 0 of 8The pattern toolbox

  1. SOLID: five principles, read on real code 23
  2. Design patterns: named shapes you already use 24
  3. DDD building blocks: inside one context 25
  4. Messaging: queues, delivery guarantees and dead letters 26
  5. Outbox and sagas: when one change spans two systems 27
  6. CQRS and event sourcing 28
  7. Resilience: stop one failure from spreading 29
  8. Observability: logs, metrics, traces 30

Built to last: 0 of 5Built to last

  1. API design and versioning 31
  2. Schema and data migrations 32
  3. Threat modeling 33
  4. Scaling data 34
  5. Testing strategy 35

The architect's job: 0 of 5The architect's job

  1. Fitness functions: decisions that check themselves 36
  2. Evolving a live system without stopping it 37
  3. Reviewing a design: scenarios, doors, failures 38
  4. One decision, three audiences 39
  5. Your first kata: a whole design in 15 minutes 40