Architecture Patterns and Methodologies

C4 Model -- Hierarchical Architecture Visualization

Four levels for different audiences:

1. System Context: system + users + external systems (stakeholder view)
2. Containers: applications, data stores, deployment units (technical overview)
3. Components: internal modules within containers (developer view)
4. Code: class/module level (optional, often auto-generated)

Notation/tooling independent. Reduces communication overhead, shared visual language across stakeholders.

Hexagonal Architecture (Ports and Adapters)

Isolate business logic from infrastructure through ports (interfaces) and adapters (implementations).

• Ports: technology-agnostic interfaces for external communication
• Primary ports (driving): REST controllers, CLI handlers, message consumers -- inbound
• Secondary ports (driven): DB repos, external service clients, filesystem -- outbound
• Adapters: technology-specific port implementations

Benefits: testability (isolated core) | flexibility (swap infrastructure) | technology independence | maintainability

Testing: unit tests through driving ports, mock driven ports | integration tests with real infrastructure | acceptance tests end-to-end through primary ports

Architectural Pattern Selection

Layered Architecture

Horizontal layers with defined dependencies. Use for: traditional enterprise apps, clear separation. Trade-off: familiar but potential overhead, layer coupling.

Microservices

Independent deployable services per capability. Use for: large teams, component scaling, tech diversity. Trade-off: scalability vs operational complexity. 2025 consensus: "start monolith, evolve when needed." Modular monolith = valid middle ground.

Event-Driven Architecture

Components communicate via events through broker. Use for: real-time, complex processes, loose coupling. Trade-off: scalability/decoupling vs event ordering, debugging.