Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Chapter I · Area 03 of 12

Principles & boundaries

The Question for Our ShopWhat should the invoicing module know about an order, and what should stay hidden?

These principles help you to distribute tasks clearly and to control dependencies in a targeted manner.

6 Building blocks

Starting hereCoupling

Three questions for every cut

  1. What belongs together?

    Cohesion

    Price rules, product texts and range are kept together in the catalogue.

  2. Which parts may depend on which others?

    Dependencies

    Invoice knows only number, address and amount – not the order tables.

  3. How much structure is worthwhile?

    Proportion

    Order and invoice stay in the modular monolith for now.

Known names – and where they are

Together, these principles are the tactics for changeability.Modifiability

This is how the building blocks hang together

Coupling, cohesion and separation show which responsibilities belong together. Module boundaries make ownership and access concrete, dependency inversion orders dependencies, and simplicity keeps the design sustainable.

ConceptModule boundariesModule boundaries define which data and capabilities a module owns and which contracts others use to access them.ConceptCouplingshows how changes spread across module boundaries and shared assumptionsConceptCohesiongroups tasks and data that share a business reason for changePrincipleSeparation of responsibilitiesassigns each reason for change to a suitable responsibilityPrincipleDependency Inversionaligns source code dependencies with the contracts at module boundariesPrincipleSimplicity & complexity budgetweighs the benefit and follow-on costs of additional boundaries and mechanisms
Relations: Coupling shows how changes spread across module boundaries and shared assumptions; Cohesion groups tasks and data that share a business reason for change; Separation of responsibilities assigns each reason for change to a suitable responsibility; Dependency Inversion aligns source code dependencies with the contracts at module boundaries; Simplicity & complexity budget weighs the benefit and follow-on costs of additional boundaries and mechanisms.

Your learning path through the area

Here you find principles for responsibilities, dependencies and module boundaries. They help you assign changes precisely, design contracts between modules and deliberately limit ongoing effort. Each building block shows its theme at our shop.

  1. Coupling

    This is what you learnYou can recognize specific dependencies and explain their change effect between shop modules.

    In the shopThe invoice module requires order number, invoice address and total amount. It should neither read internal order tables nor know the complete shopping cart.

    Coupling Open

  2. Cohesion

    This is what you learnYou can bundle tasks with the same business change reason into one module.

    In the shopPrice determination, product description and product range view change for catalogue reasons. Payment authorization and payment status, on the other hand, follow rules of payment.

    Cohesion Open

  3. Separation of responsibilities

    This is what you learnYou can assign business rules, sequence control and technical provider access to separate responsibilities.

    In the shopWhen making a payment, business status rules, the order process and the provider’s API change for various reasons. The shop separates these tasks into suitable building blocks.

    Separation of responsibilities Open

  4. Module boundaries

    This is what you learnYou can designate ownership, public abilities, and prohibited access to a module boundary.

    In the shopIn the modular shop, the storage module has stocks and reservations. The ordering module may reserve stock, but does not directly change a storage table.

    Module boundaries Open

  5. Dependency Inversion

    This is what you learnYou can replace a technical provider behind a contract defined by the core.

    In the shopThe payment module requires the ability to authorize an amount. It defines its own contract for this; an adapter translates it to an external payment provider.

    Dependency Inversion Open

  6. Simplicity & complexity budget

    This is what you learnYou can evaluate an additional architectural mechanism based on its concrete benefits and ongoing costs.

    In the shopThe shop team checks whether order and invoice require separate services. They are currently working in a modular monolith with joint release.

    Simplicity & complexity budget Open
Afterwards in the learning path · area 04Domain modelling

Thinking ahead

These areas are technically directly related to Principles & boundaries together.

Chapter I · Area 01Fundamentals & orientationThe fundamentals place architectural terms and complexity in context; these principles build on them.Open area Chapter I · Area 04Domain modellingDomain terms and model boundaries give important hints for where to draw module boundaries.Open area Chapter II · Area 05Styles & patternsArchitectural styles turn principles into recurring structures and operating forms.Open area Chapter III · Area 11Evolution & assessmentFitness functions and architecture reviews check whether important boundaries are maintained over time.Open area From practiceOne order, two systemsHow a business change connects data, messages and error handling.Opening up the scenario