Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Chapter II · Area 05 of 12

Styles & patterns

The Question for Our ShopDoes the shop stay a modular monolith, or does shipping become a separate service?

Here you will find architectural styles and patterns with their benefits, their prerequisites and their consequences.

8 Building blocks

Starting hereLayered Architecture

Three questions for every structure

  1. How is the shop divided and deployed as a whole?

    Whole system

    Seven modules, one deployment; shipping as a separate service is an assessed variant.

  2. How is a module organised internally?

    Internal structure

    Checkout in four layers; payment with port and provider adapter.

  3. How do changes and data flow?

    Data flow

    OrderPaid triggers shipping and invoice; the CSV import runs in steps.

Known names – and where they are

Does the shop stay a modular monolith? Yes. Shipping becomes a separate service only when its own team must release it independently. Styles can be combined.Microservices

This is how the building blocks hang together

The modular monolith is at the centre. Layers and hexagonal structure build up its modules internally, microservices extract individual modules. Event-driven architecture, CQRS, event sourcing and pipe and filter govern how changes and data flow.

StyleModular monolithA modular monolith separates domains within a single application deployed as one unit.StyleLayered Architectureorganises technical responsibilities within business modulesStyleHexagonal architectureconnects a module's domain core to its environment via ports and adaptersStyleMicroservicesprovide business-defined modules as independently operated servicesStyleEvent-driven Architecturepasses on business changes that other building blocks react toPatternCQRSseparates write and read paths when requirements differ significantlyPatternEvent Sourcingstores a component's changes as a sequence of events instead of only its current statePatternPipe & Filterbreaks down data processing, such as the catalogue import, into steps with clear formats
Relations: Layered Architecture organises technical responsibilities within business modules; Hexagonal architecture connects a module's domain core to its environment via ports and adapters; Microservices provide business-defined modules as independently operated services; Event-driven Architecture passes on business changes that other building blocks react to; CQRS separates write and read paths when requirements differ significantly; Event Sourcing stores a component's changes as a sequence of events instead of only its current state; Pipe & Filter breaks down data processing, such as the catalogue import, into steps with clear formats.

Your learning path through the area

Architectural styles answer different questions: how the shop is divided as a whole, how a module is structured internally and how data flows. You can combine them, for example hexagonal in the payment module of a modular monolith. Each building block shows its theme at our shop.

  1. Layered Architecture

    Internal structure

    This is what you learnYou can assign a shop function to a presentation, application, specialist or infrastructure task.

    In the shopThe checkout of the modular shop monolith accepts an order, checks business rules and saves the result in SQL.

    Layered Architecture Open

  2. Modular monolith

    Whole system

    This is what you learnYou can specify a responsibility and a permitted transition for all seven shop modules.

    In the shopThe outgoing shop delivers catalogue, shopping cart, order, payment, warehouse, shipping and invoice together. Only the payment provider is outside.

    Modular monolith Open

  3. Microservices

    Whole system

    This is what you learnBased on change and operational requirements, you can justify whether a shop module justifies its own service.

    In the shopVariant: The shop separates the shipment as a separate service, because a separate team publishes and scales it independently. The remaining six modules remain in the modular monolith; the payment provider remains external.

    Microservices Open

  4. Hexagonal architecture

    Internal structure

    This is what you learnYou can distinguish between the specialist core, port and adapter for a payment connection.

    In the shopThe internal payment module of the modular monolith decides on payment states. A provider adapter translates its port into the external API.

    Hexagonal architecture Open

  5. Event-driven Architecture

    Data flow

    This is what you learnFor an order event, you can name the producer, event content and independent reactions.

    In the shopIn modular monoliths, order publishes internally the event OrderPaid. Shipping and invoice respond with their own tasks.

    Event-driven Architecture Open

  6. CQRS

    Data flow

    This is what you learnYou can design a writing model and a reading view for the same order with different fields.

    In the shopOrder checks status transitions in the writing model. The customer service reads a flat overview with payment, shipping and invoice number.

    CQRS Open

  7. Event Sourcing

    Data flow

    This is what you learnYou can derive the current order status from an ordered sequence of events.

    In the shopAn experimental order component stores each accepted change to B-1042 as an event. The rest of the shop remains a modular monolith.

    Event Sourcing Open

  8. Pipe & Filter

    Data flow

    This is what you learnYou can break down a product import into steps with clear inputs and outputs.

    In the shopThe catalogue imports a CSV file with new cups every morning. Invalid lines should be logged without falsifying valid product data.

    Pipe & Filter Open
Afterwards in the learning path · area 06Data & state

Thinking ahead

These areas are technically directly related to Styles & patterns together.

Chapter I · Area 02Requirements & qualityQuality goals and constraints show which structural consequences matter for the project.Open area Chapter I · Area 03Principles & boundariesCoupling, cohesion and module boundaries provide criteria for comparing styles.Open area Chapter II · Area 07Communication & APIsAPIs, messages and events make collaboration between modules and services concrete.Open area Chapter III · Area 12Documentation & communicationC4 and arc42 document the chosen structure and its rationale for the team.Open area From practiceOne order, two systemsHow a business change connects data, messages and error handling.Opening up the scenario