Software Architecture on Software Engineering Learning Paths

Architecture Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

Architecture Fundamentals#

Software architecture is the set of significant decisions about the organization of a software system — the selection of structural elements and their interfaces, their behavior as specified in collaborations, and the composition of these elements into progressively larger subsystems.

What Is Software Architecture?#

Architecture is not about the code. It’s about the decisions that are costly to change. These decisions shape the system’s ability to meet both functional requirements and quality attributes.

Design Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Design Patterns#

Design patterns are reusable solutions to common problems in software design. They are not ready-made code — they are templates for solving problems that occur repeatedly in different contexts. Understanding when (and when not) to apply them is a core architectural skill.

Pattern Categories#

graph TD
 DP[Design Patterns] --> C[Creational]
 DP --> S[Structural]
 DP --> B[Behavioral]
 
 C --> C1[Singleton]
 C --> C2[Factory Method]
 C --> C3[Abstract Factory]
 C --> C4[Builder]
 C --> C5[Prototype]
 
 S --> S1[Adapter]
 S --> S2[Facade]
 S --> S3[Decorator]
 S --> S4[Proxy]
 S --> S5[Composite]
 
 B --> B1[Strategy]
 B --> B2[Observer]
 B --> B3[Command]
 B --> B4[State]
 B --> B5[Template Method]

Category	Purpose	Key Question
Creational	Object creation mechanisms	How should objects be created?
Structural	Object composition and relationships	How should objects be composed?
Behavioral	Object communication and responsibility	How should objects communicate?

Creational Patterns#

Singleton#

Ensures a class has only one instance and provides a global access point.

Clean Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Clean Architecture#

Clean Architecture, introduced by Robert C. Martin, organizes code so that business rules are independent of frameworks, databases, and delivery mechanisms. The core idea is simple: dependencies point inward, and the inner layers know nothing about the outer layers.

The Dependency Rule#

Source code dependencies must point only inward, toward higher-level policies.

Nothing in an inner circle can know anything about something in an outer circle. The name of something declared in an outer circle must not be mentioned by code in an inner circle — functions, classes, variables, or any named software entity.

Domain-Driven Design

Mon, 01 Jan 0001 00:00:00 +0000

Domain-Driven Design#

Domain-Driven Design (DDD) is an approach to software development that centers the design on the core business domain. It provides strategic patterns for organizing large systems and tactical patterns for modeling complex business logic.

Strategic DDD#

Strategic DDD addresses the big picture — how to decompose a large system into manageable parts that can evolve independently.

Ubiquitous Language#

The most fundamental concept in DDD: a shared language between developers and domain experts that is used consistently in code, conversations, and documentation.

Event-Driven Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Event-Driven Architecture#

Event-Driven Architecture (EDA) is a paradigm where the production, detection, consumption, and reaction to events drives the system’s behavior. Instead of direct calls between services, components communicate through events — facts about things that happened.

Event Types#

Not all events are equal. Understanding the type helps you choose the right infrastructure and guarantees.

Type	Purpose	Content	Example
Domain Event	Records what happened in the domain	Full state at time of event	`BookingConfirmed { booking_id, guest, dates, total }`
Integration Event	Communicates across bounded contexts	Minimal data + references	`BookingConfirmed { booking_id, guest_id }`
Notification Event	Signals something happened (no data)	Event type + aggregate ID only	`BookingConfirmed { booking_id }`

Domain Events#

Rich events used within a bounded context. They contain enough information for any handler within the same context to act.

Monolith to Microservices

Mon, 01 Jan 0001 00:00:00 +0000

Monolith to Microservices#

Migrating from a monolith to microservices is one of the most impactful — and risky — architectural transitions a team can undertake. Success requires a deliberate, incremental strategy rather than a big-bang rewrite.

Why Migrate?#

Driver	Monolith Pain	Microservices Solution
Deployment speed	Entire app redeployed for any change	Deploy services independently
Team scaling	Merge conflicts, coordination overhead	Teams own independent services
Technology lock-in	One stack for everything	Polyglot — best tool per service
Fault isolation	One bug crashes everything	Failures contained per service
Scalability	Scale entire app for one hot path	Scale individual services

When NOT to Migrate#

Small team (< 10 engineers)
Well-understood domain with stable requirements
No deployment bottleneck
You cannot invest in platform infrastructure (CI/CD, observability, service mesh)

The Modular Monolith — First Step#

Before extracting services, modularize within the monolith:

Architectural Patterns

Mon, 01 Jan 0001 00:00:00 +0000

Architectural Patterns#

Architectural patterns are proven structural templates for organizing software systems. Each pattern makes different tradeoffs between complexity, scalability, flexibility, and maintainability. Choosing the right one depends on your constraints and quality attributes.

Layered Architecture#

The most common pattern — organizes code into horizontal layers with strict dependency rules:

┌─────────────────────────────┐
│ Presentation Layer │ UI, API endpoints
├─────────────────────────────┤
│ Business Logic Layer │ Domain rules, workflows
├─────────────────────────────┤
│ Persistence Layer │ Data access, repositories
├─────────────────────────────┤
│ Database Layer │ Storage engines
└─────────────────────────────┘
 Dependencies flow DOWN only

Aspect	Details
Principle	Each layer only depends on the layer directly below
Variants	Strict (only adjacent layers) vs relaxed (skip layers)
Strengths	Simple, well-understood, good separation of concerns
Weaknesses	Monolithic deployments, changes ripple through layers
Best for	Traditional business applications, CRUD systems, small teams

Sinkhole Anti-Pattern#

When requests pass through layers without adding value — just forwarding calls. If > 20% of requests are sinkholes, the architecture is over-layered.

Architecture Decisions

Mon, 01 Jan 0001 00:00:00 +0000

Architecture Decisions#

Every software system is shaped by hundreds of decisions — technology choices, structural patterns, integration approaches. The best teams make these decisions explicitly, traceably, and reversibly. Architecture Decision Records (ADRs) are the primary tool for this discipline.

Architecture Decision Records (ADRs)#

An ADR documents one significant architectural decision along with its context, rationale, and consequences.

Standard Format#

# ADR-001: Use PostgreSQL for order storage

## Status
Accepted (2024-03-15)

## Context
The orders service needs persistent storage supporting:
- ACID transactions for financial data
- Complex queries for reporting
- High write throughput (10K orders/hour peak)

We considered PostgreSQL, DynamoDB, and MongoDB.

## Decision
We will use PostgreSQL (via AWS RDS).

## Consequences
### Positive
- Strong consistency guarantees
- Rich query capabilities (JOIN, aggregates)
- Team expertise exists

### Negative
- Vertical scaling limits (vs DynamoDB)
- Operational overhead (backups, failover)
- Schema migrations required for changes

### Risks
- May need read replicas at 100K orders/hour

ADR Lifecycle#

Status	Meaning
Proposed	Under discussion, not yet approved
Accepted	Approved and active
Deprecated	No longer recommended but existing code may use it
Superseded	Replaced by another ADR (link to successor)

Where to Store ADRs#

Location	Pros	Cons
Repository (`docs/adr/`)	Versioned with code, close to context	Scattered across repos
Wiki/Confluence	Searchable, cross-project visibility	Not versioned with code
Dedicated ADR repo	Central registry, easy to browse	Disconnected from implementation

Recommendation: Store in the repo for service-specific decisions; use a central wiki for cross-cutting decisions.