Common architecture styles

Key features

• Layered: presentation → service → repository → database, each layer calling only the one directly below it
• Modular monolith: one deployable process, split into feature modules with enforced boundaries between them
• Clean/hexagonal: business rules depend on nothing; infrastructure (DB, web, CLI) depends inward on the business rules through interfaces
• Hexagonal names the same idea "ports and adapters" — a port is an interface the core defines, an adapter is the concrete implementation plugged in
• None of the four dictate a specific framework — they dictate which direction an import is allowed to point

Command

# The dependency always points one way: presentation -> service -> repository
class OrderRepository:
    def get(self, order_id): ...

class OrderService:
    def __init__(self, repository: OrderRepository):
        self.repository = repository   # injected, not imported directly

    def get_order_total(self, order_id):
        return self.repository.get(order_id)["total"]

Key features

• Ubiquitous language: code and business conversation use the exact same terms — "Order", not "Record" or "Row"
• Value object: defined only by its data, no identity — two Money(10, "USD") are interchangeable, and it is immutable
• Entity: has identity that persists across changes — the same Order stays "the same order" after its total changes
• Aggregate: a cluster of entities/value objects with one root; outside code may only reach it through the root
• Bounded context: a model is only valid within one explicit boundary — "Customer" can mean different things in Billing vs. Support

Command

class Money:                      # value object — no identity, immutable
    def __init__(self, amount, currency="USD"):
        self.amount, self.currency = amount, currency

class Order:                      # entity — has identity (order_id), and owns the invariant
    def __init__(self, order_id):
        self.order_id = order_id
        self._lines = []

    def add_line(self, product_id, quantity, unit_price):
        if quantity <= 0:
            raise ValueError("quantity must be positive")   # rule lives here, not at every call site
        self._lines.append((product_id, quantity, unit_price))

Key features

• Microservices: independently deployable services, each owning its own data store — no shared database
• The cost of microservices is operational: network calls replace function calls, and failures/latency become distributed problems
• Event-driven: a publisher emits an event without knowing which services subscribe to it, or how many
• Events decouple services in time as well as identity — a subscriber can be down when the event is published and catch up later, if the bus persists it
• Choosing microservices/event-driven for a small team or low scale often adds coordination cost with no matching benefit — a modular monolith is the usual middle ground

Command

class EventBus:
    def __init__(self):
        self._handlers = {}

    def subscribe(self, event_name, handler):
        self._handlers.setdefault(event_name, []).append(handler)

    def publish(self, event_name, payload):
        for handler in self._handlers.get(event_name, []):
            handler(payload)          # each subscriber reacts independently