SRP at Different Levels - Learning Module

Loading content...

0/246

SRP at the Architecture Level — Services, Subsystems, and Boundaries

The Monolith That Couldn't Scale

A fast-growing e-commerce company hit a wall. Their single deployment—handling product catalog, inventory, orders, payments, shipping, and customer service—required 4-hour deploys. A bug in the payment module meant rolling back catalog updates. Black Friday traffic on the product pages crashed the order processing. The entire engineering team of 80 people worked in the same codebase, creating merge conflicts, stepping on each other's changes, and waiting in deployment queues.

The root cause wasn't that they had a monolith. The problem was that their monolith had no internal architecture—no clear boundaries, no separation of concerns, no single responsibilities at the system level.

SRP at the architecture level is about designing systems where major components have focused purposes, enabling independent evolution, scaling, and team ownership. Whether you build monoliths or microservices, architectural SRP is essential for sustainable systems.

What You Will Master

By the end of this page, you will understand how SRP manifests at the architectural scale—how to identify service boundaries, design bounded contexts, structure subsystems for independent deployability, and make informed decisions about system decomposition. You'll see SRP as the guiding principle for scalable architecture.

Architectural Responsibility Defined

At the architectural level, SRP can be stated as:

Each major system component (service, subsystem, bounded context) should have one clear business capability it provides and one cohesive reason to change.

This is the actor-based definition of SRP scaled up. Instead of asking 'which stakeholder drives changes to this class?', we ask:

Which business domain does this service represent?
Which team is accountable for this subsystem?
What single capability does this component provide to the rest of the system?

When a service has multiple, unrelated reasons to change—different business domains, different stakeholders, different rate of change—it violates architectural SRP.

Architectural SRP Across Scales
Architecture Pattern	SRP Unit	SRP Question
Modular Monolith	Module/Package	Does this module represent one cohesive domain capability?
Microservices	Service	Does this service own one bounded context or business capability?
Event-Driven	Event Producer/Consumer	Does this component handle one category of domain events?
Layered Architecture	Layer	Does this layer handle one type of concern (presentation, business, data)?
Hexagonal/Ports & Adapters	Port/Adapter	Does each port represent one external interaction type?

The Team Test

A strong signal for correct architectural SRP: Can one team own and operate this component independently? If a service requires constant coordination between 3 teams, it likely conflates multiple responsibilities. If one team can deliver features end-to-end within a service, boundaries are probably right.

Bounded Contexts and Domain-Driven Design

Domain-Driven Design (DDD) provides a powerful framework for identifying architectural SRP boundaries through the concept of Bounded Contexts.

A Bounded Context is a boundary within which a particular domain model applies. Different bounded contexts may use different models, even for concepts with the same name.

Consider 'Customer':

In the Sales context: Customer has contact info, purchase history, preferred payment methods
In the Shipping context: Customer has delivery addresses, shipping preferences, package instructions
In the Support context: Customer has ticket history, satisfaction score, communication preferences

These are different models with different data and behavior, owned by different teams, changing for different reasons. Trying to create a single 'Customer' that serves all contexts violates architectural SRP—any change ripples everywhere.

BoundedContexts.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// EACH BOUNDED CONTEXT HAS ITS OWN MODEL
 
// === SALES CONTEXT ===
package com.company.sales;
 
public class Customer {  // Sales' view of Customer
    private CustomerId id;
    private ContactInfo contact;
    private List<PaymentMethod> paymentMethods;
    private PurchaseHistory history;
    private CustomerSegment segment;  // Gold, Silver, Bronze
    
    public boolean isEligibleForDiscount(Promotion promo) { ... }
    public Money calculateLoyaltyDiscount() { ... }
}
 
// === SHIPPING CONTEXT ===
package com.company.shipping;
 
public class Customer {  // Shipping's view of Customer
    private CustomerId id;
    private List<DeliveryAddress> addresses;
    private DeliveryPreferences preferences;  // Leave at door, signature required
    private List<DeliveryInstruction> instructions;
    
    public DeliveryAddress getDefaultAddress() { ... }
    public boolean requiresSignature() { ... }
}
 
// === SUPPORT CONTEXT ===  
package com.company.support;
 
public class Customer {  // Support's view of Customer
    private CustomerId id;
    private List<SupportTicket> ticketHistory;
    private SatisfactionScore csat;
    private CommunicationPreferences prefs;  // Email, phone, chat
    
    public Priority calculateTicketPriority() { ... }
    public boolean isAtRisk() { ... }  // Churn risk based on tickets
}
 
// CustomerId is the ONLY shared concept (anti-corruption layer)
// Each context owns its complete model independently

Context Mapping

When bounded contexts need to interact, they do so through well-defined integration patterns: Shared Kernel (truly shared concepts), Customer-Supplier (one context serves another), Anti-Corruption Layer (translating between models), or Published Language (agreed-upon API contracts). These patterns preserve each context's SRP while enabling collaboration.

Service Decomposition Criteria

When decomposing a system into services (whether microservices or modules in a modular monolith), several criteria help identify SRP-compliant boundaries:

Decomposition Criteria

•Business Capability — Each service represents one business capability (Order Management, Payment Processing, Inventory Tracking). Ask: 'What does this service DO for the business?'
•Subdomain — Each service maps to a subdomain in your domain (Core, Supporting, or Generic). Different subdomains have different change drivers.
•Data Ownership — Each service owns and is authoritative for certain data. If two services need the same data, who owns it? Shared ownership indicates unclear boundaries.
•Team Ownership — Each service should be ownable by a single team. If a service requires 3 teams to modify, it's likely too big or poorly bounded.
•Rate of Change — Components that change at different rates should be separate. A stable payment integration shouldn't be in the same service as rapidly evolving promotions logic.
•Scaling Requirements — Components with different scaling needs should be separate. Product catalog (read-heavy) has different scaling needs than order processing (write-heavy).

The Decomposition Decision Matrix:

When evaluating whether to split a component, consider multiple factors:

Should These Be Separate Services?
Factor	Keep Together	Split Apart
Change Velocity	Change together at same rate	Change independently, different rates
Team Structure	Same team owns both	Different teams own each
Data Coupling	Share transactional data	Only need eventual consistency
Scaling Profile	Similar load patterns	Vastly different scaling needs
Deployment Risk	Must deploy atomically	Can deploy independently
Domain Cohesion	Same bounded context	Different bounded contexts

Don't Over-Decompose

The goal isn't maximum decomposition—it's appropriate decomposition. Too many services create distributed systems complexity: network latency, partial failures, data consistency challenges, debugging difficulty. Start with larger, cohesive services and split when pain emerges, not preemptively.

Signs of Architectural SRP Violations

Architectural SRP violations create systemic problems that become increasingly painful as the system grows. Learning to recognize these patterns early prevents years of accumulated debt.

Warning Signs of Architectural SRP Violation

•Shotgun Surgery at Scale — A single business change requires deploying 5+ services simultaneously. Indicates responsibilities are scattered.
•Deployment Coupling — 'We can't deploy Service A without also deploying Service B.' Services should be independently deployable.
•Shared Database Anti-pattern — Multiple services read from and write to the same database tables. Data ownership is unclear; changes cascade unpredictably.
•Distributed Monolith — Services call each other synchronously for every operation. You have a monolith's coupling with microservices' network overhead—the worst of both worlds.
•Cross-Service Transactions — Business operations require coordinating transactions across services. A sign that what should be one service was artificially split.
•'Core' Service Syndrome — One service that every other service depends on, doing too much. It becomes the bottleneck for every team.
•Constant Inter-Team Coordination — Teams frequently blocked waiting for other teams' changes. Boundaries don't align with organizational structure.

DistributedMonolith.txt

plain text

# DISTRIBUTED MONOLITH ANTI-PATTERN
 
User Request Flow:
┌──────────────────────────────────────────────────────────────────┐
│ 1. API Gateway receives "Create Order" request                   │
│    ↓                                                             │
│ 2. Order Service calls Product Service (sync) to validate items │
│    ↓                                                             │
│ 3. Order Service calls Inventory Service (sync) to check stock  │
│    ↓                                                             │
│ 4. Order Service calls Pricing Service (sync) to calculate total│
│    ↓                                                             │
│ 5. Order Service calls User Service (sync) to get shipping addr │
│    ↓                                                             │
│ 6. Order Service calls Payment Service (sync) to process payment│
│    ↓                                                             │
│ 7. Order Service calls Shipping Service (sync) to create shipment│
│    ↓                                                             │
│ 8. Order Service calls Notification Service (sync) to send email│
└──────────────────────────────────────────────────────────────────┘
 
Problems:
- 8 synchronous network calls for ONE operation
- If ANY service is slow or down, entire operation fails
- Latency = sum of all service latencies
- Services can't be deployed independently (orchestration logic in Order Service)
- This is a monolith distributed across network boundaries
 
Root Cause: Services split by technical layer, not by business capability
Order Service has become a "God Service" orchestrating everything

The Integration Test Smell

If testing one service requires spinning up 5 other services, you have coupling issues. A well-bounded service should be testable with stubs/mocks for its collaborators. If integration tests are the only way to verify behavior, boundaries may be wrong.

Designing Event-Driven Boundaries

Event-driven architectures provide a natural way to maintain SRP at the architectural level by decoupling services through asynchronous events rather than synchronous calls. Each service becomes responsible for:

Its own domain operations
Publishing events about what happened in its domain
Reacting to events from other domains (if relevant)

This preserves SRP because each service focuses on its bounded context and communicates through loosely-coupled events.

EventDrivenSRP.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// EACH SERVICE HAS SINGLE RESPONSIBILITY + EVENTS
 
// === ORDER SERVICE ===
// Responsibility: Order lifecycle management
public class OrderService {
    private final EventPublisher events;
    
    public Order createOrder(CreateOrderCommand cmd) {
        // 1. Validate within OUR context (basic order rules)
        validateOrderRequest(cmd);
        
        // 2. Create order in PENDING state
        Order order = Order.create(cmd);
        orderRepository.save(order);
        
        // 3. Publish event - let other contexts react
        events.publish(new OrderCreated(order.getId(), order.getItems()));
        
        return order;  // Order service is DONE - single responsibility
    }
    
    // React to external events
    @EventHandler
    public void on(PaymentCompleted event) {
        Order order = orderRepository.find(event.getOrderId());
        order.confirmPayment();
        orderRepository.save(order);
        events.publish(new OrderConfirmed(order.getId()));
    }
}
 
// === INVENTORY SERVICE ===
// Responsibility: Stock management
public class InventoryService {
    
    @EventHandler
    public void on(OrderCreated event) {
        // React to orders by reserving stock
        for (OrderItem item : event.getItems()) {
            inventory.reserve(item.getProductId(), item.getQuantity());
        }
        events.publish(new StockReserved(event.getOrderId()));
    }
}
 
// === PAYMENT SERVICE ===
// Responsibility: Payment processing
public class PaymentService {
    
    @EventHandler  
    public void on(StockReserved event) {
        // Stock confirmed, now process payment
        PaymentResult result = processPayment(event.getOrderId());
        events.publish(result.isSuccess() 
            ? new PaymentCompleted(event.getOrderId())
            : new PaymentFailed(event.getOrderId(), result.getReason()));
    }
}
 
// Benefits:
// - Each service does ONE thing
// - Services don't call each other synchronously
// - Services can evolve independently
// - If one service is slow, others aren't blocked
// - Easy to add new services that react to events

Event-Driven Benefits

•Temporal decoupling
•Independent deployability
•Easy to add new consumers
•Natural audit log
•Resilience to failures

Event-Driven Challenges

•Eventual consistency
•Event ordering complexity
•Debugging distributed flows
•Event schema evolution
•Observability requirements

Events as Contracts

Events become the API between bounded contexts. They must be designed as carefully as REST APIs: versioned, backward-compatible, and capturing business meaning. Events like 'OrderCreated' are stable; internal implementation can change freely.

Layered and Hexagonal Architectures

Layered Architecture and Hexagonal Architecture (Ports & Adapters) are architectural patterns that embody SRP by separating concerns into distinct structural units.

Layered Architecture:

Traditional layers each have single responsibilities:

Presentation Layer: Handle user interaction, format output
Application/Service Layer: Orchestrate use cases, coordinate domain
Domain Layer: Business logic, rules, invariants
Infrastructure Layer: Technical concerns—databases, messaging, external APIs

SRP is enforced by layer: UI changes don't affect domain logic; database changes don't affect presentation.

HexagonalArchitecture.txt

plain text

# HEXAGONAL ARCHITECTURE (PORTS & ADAPTERS)
 
                    ┌─────────────────────────────────────┐
                    │           ADAPTERS (Driving)         │
                    │  REST      GraphQL    CLI    Message │
                    │  Controller  Resolver  Cmd   Handler │
                    └────────────────┬────────────────────┘
                                     │ Ports (Interfaces)
                                     ▼
         ┌───────────────────────────────────────────────────────┐
         │                   APPLICATION CORE                     │
         │  ┌─────────────────────────────────────────────────┐  │
         │  │              APPLICATION SERVICES                │  │
         │  │    Use Cases / Commands / Queries / Handlers    │  │
         │  └─────────────────────────────────────────────────┘  │
         │  ┌─────────────────────────────────────────────────┐  │
         │  │                  DOMAIN MODEL                    │  │
         │  │   Entities / Value Objects / Domain Services    │  │
         │  │   Aggregates / Domain Events / Business Rules   │  │
         │  └─────────────────────────────────────────────────┘  │
         └───────────────────────────────────────────────────────┘
                                     │ Ports (Interfaces)
                                     ▼
                    ┌─────────────────────────────────────┐
                    │          ADAPTERS (Driven)           │
                    │  Database   External   Email   File  │
                    │  Repository  API       Service System│
                    └─────────────────────────────────────┘
 
SRP IN HEXAGONAL:
- CORE has SINGLE responsibility: Business logic
- Each ADAPTER has SINGLE responsibility: Translate one external concern
- PORTS define contracts; implementations can be swapped
- Core doesn't know about HTTP, SQL, or any infrastructure

Key SRP Implications:

The domain core has no infrastructure dependencies — It focuses purely on business rules
Each adapter is focused — One adapter per external system type
Ports are minimal contracts — Express only what the core needs
Testing is simplified — Mock adapters to test core in isolation

This structure enforces SRP at the architectural level within a single deployable unit—whether monolith or microservice.

The Dependency Rule

In both layered and hexagonal architectures, dependencies point INWARD. Outer layers (adapters, presentation) depend on inner layers (domain, application). The core business logic never depends on infrastructure. This protects the domain's SRP—it changes only for business reasons, not technical ones.

Case Study: E-Commerce Decomposition

Let's apply architectural SRP to a realistic e-commerce platform, showing how business capabilities map to service boundaries.

EcommerceDecomposition.txt

plain text

# E-COMMERCE PLATFORM - SRP-DRIVEN DECOMPOSITION
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        CUSTOMER-FACING DOMAIN                            │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│   PRODUCT CATALOG   │   SHOPPING CART     │      SEARCH & DISCOVERY    │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Product info     │   • Cart management │   • Full-text search       │
│   • Categories       │   • Pricing rules   │   • Recommendations        │
│   • Attributes       │   • Promo codes     │   • Personalization        │
│   • Media assets     │   • Cart persistence│   • Browse navigation      │
│   Team: Catalog      │   Team: Shopping    │   Team: Discovery          │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        ORDER FULFILLMENT DOMAIN                          │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│    ORDER MGMT       │     INVENTORY       │        SHIPPING            │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Order lifecycle  │   • Stock levels    │   • Carrier integration    │
│   • Order history    │   • Reservations    │   • Rate calculation       │
│   • Returns/refunds  │   • Reorder alerts  │   • Tracking               │
│   • Order events     │   • Warehouse sync  │   • Delivery scheduling    │
│   Team: Orders       │   Team: Inventory   │   Team: Logistics          │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                          FINANCIAL DOMAIN                                │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│      PAYMENTS       │       BILLING       │        TAX SERVICE         │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Payment gateway  │   • Invoice gen     │   • Tax calculation        │
│   • Fraud detection  │   • Subscription    │   • Jurisdiction rules     │
│   • Refund process   │   • Payment terms   │   • Compliance             │
│   • PCI compliance   │   • Revenue recog   │   • Reporting              │
│   Team: Payments     │   Team: Finance     │   Team: Finance            │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        CUSTOMER DOMAIN                                   │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│      IDENTITY       │       PROFILE       │        SUPPORT             │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Authentication   │   • User data       │   • Ticket management      │
│   • Authorization    │   • Preferences     │   • Chat support           │
│   • Session mgmt     │   • Order history   │   • Knowledge base         │
│   • SSO integration  │   • Saved items     │   • Customer satisfaction  │
│   Team: Identity     │   Team: Profile     │   Team: Support            │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
WHY THESE BOUNDARIES:
• Each service = one business capability
• Each service = one team ownership
• Different change velocities respected (Payments vs Catalog)
• Different scaling needs separated (Search vs Orders)
• Data ownership is clear (each service owns its data)

Evolution Not Revolution

This decomposition doesn't happen on day one. It evolves as the business and teams grow. Starting with a well-structured modular monolith that respects these boundaries internally makes later extraction into services much easier than retrofitting boundaries onto a tangled codebase.

Summary: SRP at the Architecture Level

Architectural SRP is where the principle has its greatest leverage. Get this right, and teams can work independently, systems can scale appropriately, and the organization can evolve without constant coordination overhead.

Key Takeaways

•Bounded contexts are SRP at scale — Each context has one cohesive domain model
•Decompose by business capability — Services should represent what the business does, not technical layers
•Watch for distributed monolith patterns — Synchronous chains of calls indicate poor boundaries
•Event-driven design enforces SRP — Asynchronous events decouple services naturally
•Map architecture to team structure — One team per service; Conway's Law is your friend
•Start modular, split later — Over-decomposition upfront creates unnecessary complexity

Module Complete:

We've now covered SRP at every scale—from individual methods through classes and modules to entire architectural components. SRP is a fractal principle: the same core idea (one reason to change, one actor served) applies at every level of software design. Master this, and you have a compass for countless design decisions.

Module Complete

You now understand SRP at all levels: methods should do one thing, classes should serve one actor, modules should represent one capability, and architectural components should own one bounded context. This completes your understanding of SRP at Different Levels. Apply this principle consistently, and your systems will be maintainable, testable, and evolvable for years to come.

SRP at the Architecture Level — Services, Subsystems, and Boundaries

The Monolith That Couldn't Scale

What You Will Master

Architectural Responsibility Defined

At the architectural level, SRP can be stated as:

Each major system component (service, subsystem, bounded context) should have one clear business capability it provides and one cohesive reason to change.

This is the actor-based definition of SRP scaled up. Instead of asking 'which stakeholder drives changes to this class?', we ask:

Which business domain does this service represent?
Which team is accountable for this subsystem?
What single capability does this component provide to the rest of the system?

When a service has multiple, unrelated reasons to change—different business domains, different stakeholders, different rate of change—it violates architectural SRP.

Architectural SRP Across Scales
Architecture Pattern	SRP Unit	SRP Question
Modular Monolith	Module/Package	Does this module represent one cohesive domain capability?
Microservices	Service	Does this service own one bounded context or business capability?
Event-Driven	Event Producer/Consumer	Does this component handle one category of domain events?
Layered Architecture	Layer	Does this layer handle one type of concern (presentation, business, data)?
Hexagonal/Ports & Adapters	Port/Adapter	Does each port represent one external interaction type?

The Team Test

Bounded Contexts and Domain-Driven Design

Domain-Driven Design (DDD) provides a powerful framework for identifying architectural SRP boundaries through the concept of Bounded Contexts.

A Bounded Context is a boundary within which a particular domain model applies. Different bounded contexts may use different models, even for concepts with the same name.

Consider 'Customer':

In the Sales context: Customer has contact info, purchase history, preferred payment methods
In the Shipping context: Customer has delivery addresses, shipping preferences, package instructions
In the Support context: Customer has ticket history, satisfaction score, communication preferences

BoundedContexts.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// EACH BOUNDED CONTEXT HAS ITS OWN MODEL
 
// === SALES CONTEXT ===
package com.company.sales;
 
public class Customer {  // Sales' view of Customer
    private CustomerId id;
    private ContactInfo contact;
    private List<PaymentMethod> paymentMethods;
    private PurchaseHistory history;
    private CustomerSegment segment;  // Gold, Silver, Bronze
    
    public boolean isEligibleForDiscount(Promotion promo) { ... }
    public Money calculateLoyaltyDiscount() { ... }
}
 
// === SHIPPING CONTEXT ===
package com.company.shipping;
 
public class Customer {  // Shipping's view of Customer
    private CustomerId id;
    private List<DeliveryAddress> addresses;
    private DeliveryPreferences preferences;  // Leave at door, signature required
    private List<DeliveryInstruction> instructions;
    
    public DeliveryAddress getDefaultAddress() { ... }
    public boolean requiresSignature() { ... }
}
 
// === SUPPORT CONTEXT ===  
package com.company.support;
 
public class Customer {  // Support's view of Customer
    private CustomerId id;
    private List<SupportTicket> ticketHistory;
    private SatisfactionScore csat;
    private CommunicationPreferences prefs;  // Email, phone, chat
    
    public Priority calculateTicketPriority() { ... }
    public boolean isAtRisk() { ... }  // Churn risk based on tickets
}
 
// CustomerId is the ONLY shared concept (anti-corruption layer)
// Each context owns its complete model independently

Context Mapping

Service Decomposition Criteria

When decomposing a system into services (whether microservices or modules in a modular monolith), several criteria help identify SRP-compliant boundaries:

Decomposition Criteria

•Business Capability — Each service represents one business capability (Order Management, Payment Processing, Inventory Tracking). Ask: 'What does this service DO for the business?'
•Subdomain — Each service maps to a subdomain in your domain (Core, Supporting, or Generic). Different subdomains have different change drivers.
•Data Ownership — Each service owns and is authoritative for certain data. If two services need the same data, who owns it? Shared ownership indicates unclear boundaries.
•Team Ownership — Each service should be ownable by a single team. If a service requires 3 teams to modify, it's likely too big or poorly bounded.
•Rate of Change — Components that change at different rates should be separate. A stable payment integration shouldn't be in the same service as rapidly evolving promotions logic.
•Scaling Requirements — Components with different scaling needs should be separate. Product catalog (read-heavy) has different scaling needs than order processing (write-heavy).

The Decomposition Decision Matrix:

When evaluating whether to split a component, consider multiple factors:

Should These Be Separate Services?
Factor	Keep Together	Split Apart
Change Velocity	Change together at same rate	Change independently, different rates
Team Structure	Same team owns both	Different teams own each
Data Coupling	Share transactional data	Only need eventual consistency
Scaling Profile	Similar load patterns	Vastly different scaling needs
Deployment Risk	Must deploy atomically	Can deploy independently
Domain Cohesion	Same bounded context	Different bounded contexts

Don't Over-Decompose

Signs of Architectural SRP Violations

Architectural SRP violations create systemic problems that become increasingly painful as the system grows. Learning to recognize these patterns early prevents years of accumulated debt.

Warning Signs of Architectural SRP Violation

•Shotgun Surgery at Scale — A single business change requires deploying 5+ services simultaneously. Indicates responsibilities are scattered.
•Deployment Coupling — 'We can't deploy Service A without also deploying Service B.' Services should be independently deployable.
•Shared Database Anti-pattern — Multiple services read from and write to the same database tables. Data ownership is unclear; changes cascade unpredictably.
•Distributed Monolith — Services call each other synchronously for every operation. You have a monolith's coupling with microservices' network overhead—the worst of both worlds.
•Cross-Service Transactions — Business operations require coordinating transactions across services. A sign that what should be one service was artificially split.
•'Core' Service Syndrome — One service that every other service depends on, doing too much. It becomes the bottleneck for every team.
•Constant Inter-Team Coordination — Teams frequently blocked waiting for other teams' changes. Boundaries don't align with organizational structure.

DistributedMonolith.txt

plain text

# DISTRIBUTED MONOLITH ANTI-PATTERN
 
User Request Flow:
┌──────────────────────────────────────────────────────────────────┐
│ 1. API Gateway receives "Create Order" request                   │
│    ↓                                                             │
│ 2. Order Service calls Product Service (sync) to validate items │
│    ↓                                                             │
│ 3. Order Service calls Inventory Service (sync) to check stock  │
│    ↓                                                             │
│ 4. Order Service calls Pricing Service (sync) to calculate total│
│    ↓                                                             │
│ 5. Order Service calls User Service (sync) to get shipping addr │
│    ↓                                                             │
│ 6. Order Service calls Payment Service (sync) to process payment│
│    ↓                                                             │
│ 7. Order Service calls Shipping Service (sync) to create shipment│
│    ↓                                                             │
│ 8. Order Service calls Notification Service (sync) to send email│
└──────────────────────────────────────────────────────────────────┘
 
Problems:
- 8 synchronous network calls for ONE operation
- If ANY service is slow or down, entire operation fails
- Latency = sum of all service latencies
- Services can't be deployed independently (orchestration logic in Order Service)
- This is a monolith distributed across network boundaries
 
Root Cause: Services split by technical layer, not by business capability
Order Service has become a "God Service" orchestrating everything

The Integration Test Smell

Designing Event-Driven Boundaries

Its own domain operations
Publishing events about what happened in its domain
Reacting to events from other domains (if relevant)

This preserves SRP because each service focuses on its bounded context and communicates through loosely-coupled events.

EventDrivenSRP.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
// EACH SERVICE HAS SINGLE RESPONSIBILITY + EVENTS
 
// === ORDER SERVICE ===
// Responsibility: Order lifecycle management
public class OrderService {
    private final EventPublisher events;
    
    public Order createOrder(CreateOrderCommand cmd) {
        // 1. Validate within OUR context (basic order rules)
        validateOrderRequest(cmd);
        
        // 2. Create order in PENDING state
        Order order = Order.create(cmd);
        orderRepository.save(order);
        
        // 3. Publish event - let other contexts react
        events.publish(new OrderCreated(order.getId(), order.getItems()));
        
        return order;  // Order service is DONE - single responsibility
    }
    
    // React to external events
    @EventHandler
    public void on(PaymentCompleted event) {
        Order order = orderRepository.find(event.getOrderId());
        order.confirmPayment();
        orderRepository.save(order);
        events.publish(new OrderConfirmed(order.getId()));
    }
}
 
// === INVENTORY SERVICE ===
// Responsibility: Stock management
public class InventoryService {
    
    @EventHandler
    public void on(OrderCreated event) {
        // React to orders by reserving stock
        for (OrderItem item : event.getItems()) {
            inventory.reserve(item.getProductId(), item.getQuantity());
        }
        events.publish(new StockReserved(event.getOrderId()));
    }
}
 
// === PAYMENT SERVICE ===
// Responsibility: Payment processing
public class PaymentService {
    
    @EventHandler  
    public void on(StockReserved event) {
        // Stock confirmed, now process payment
        PaymentResult result = processPayment(event.getOrderId());
        events.publish(result.isSuccess() 
            ? new PaymentCompleted(event.getOrderId())
            : new PaymentFailed(event.getOrderId(), result.getReason()));
    }
}
 
// Benefits:
// - Each service does ONE thing
// - Services don't call each other synchronously
// - Services can evolve independently
// - If one service is slow, others aren't blocked
// - Easy to add new services that react to events

Event-Driven Benefits

•Temporal decoupling
•Independent deployability
•Easy to add new consumers
•Natural audit log
•Resilience to failures

Event-Driven Challenges

•Eventual consistency
•Event ordering complexity
•Debugging distributed flows
•Event schema evolution
•Observability requirements

Events as Contracts

Layered and Hexagonal Architectures

Layered Architecture and Hexagonal Architecture (Ports & Adapters) are architectural patterns that embody SRP by separating concerns into distinct structural units.

Layered Architecture:

Traditional layers each have single responsibilities:

Presentation Layer: Handle user interaction, format output
Application/Service Layer: Orchestrate use cases, coordinate domain
Domain Layer: Business logic, rules, invariants
Infrastructure Layer: Technical concerns—databases, messaging, external APIs

SRP is enforced by layer: UI changes don't affect domain logic; database changes don't affect presentation.

HexagonalArchitecture.txt

plain text

# HEXAGONAL ARCHITECTURE (PORTS & ADAPTERS)
 
                    ┌─────────────────────────────────────┐
                    │           ADAPTERS (Driving)         │
                    │  REST      GraphQL    CLI    Message │
                    │  Controller  Resolver  Cmd   Handler │
                    └────────────────┬────────────────────┘
                                     │ Ports (Interfaces)
                                     ▼
         ┌───────────────────────────────────────────────────────┐
         │                   APPLICATION CORE                     │
         │  ┌─────────────────────────────────────────────────┐  │
         │  │              APPLICATION SERVICES                │  │
         │  │    Use Cases / Commands / Queries / Handlers    │  │
         │  └─────────────────────────────────────────────────┘  │
         │  ┌─────────────────────────────────────────────────┐  │
         │  │                  DOMAIN MODEL                    │  │
         │  │   Entities / Value Objects / Domain Services    │  │
         │  │   Aggregates / Domain Events / Business Rules   │  │
         │  └─────────────────────────────────────────────────┘  │
         └───────────────────────────────────────────────────────┘
                                     │ Ports (Interfaces)
                                     ▼
                    ┌─────────────────────────────────────┐
                    │          ADAPTERS (Driven)           │
                    │  Database   External   Email   File  │
                    │  Repository  API       Service System│
                    └─────────────────────────────────────┘
 
SRP IN HEXAGONAL:
- CORE has SINGLE responsibility: Business logic
- Each ADAPTER has SINGLE responsibility: Translate one external concern
- PORTS define contracts; implementations can be swapped
- Core doesn't know about HTTP, SQL, or any infrastructure

Key SRP Implications:

The domain core has no infrastructure dependencies — It focuses purely on business rules
Each adapter is focused — One adapter per external system type
Ports are minimal contracts — Express only what the core needs
Testing is simplified — Mock adapters to test core in isolation

This structure enforces SRP at the architectural level within a single deployable unit—whether monolith or microservice.

The Dependency Rule

Case Study: E-Commerce Decomposition

Let's apply architectural SRP to a realistic e-commerce platform, showing how business capabilities map to service boundaries.

EcommerceDecomposition.txt

plain text

# E-COMMERCE PLATFORM - SRP-DRIVEN DECOMPOSITION
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        CUSTOMER-FACING DOMAIN                            │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│   PRODUCT CATALOG   │   SHOPPING CART     │      SEARCH & DISCOVERY    │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Product info     │   • Cart management │   • Full-text search       │
│   • Categories       │   • Pricing rules   │   • Recommendations        │
│   • Attributes       │   • Promo codes     │   • Personalization        │
│   • Media assets     │   • Cart persistence│   • Browse navigation      │
│   Team: Catalog      │   Team: Shopping    │   Team: Discovery          │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        ORDER FULFILLMENT DOMAIN                          │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│    ORDER MGMT       │     INVENTORY       │        SHIPPING            │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Order lifecycle  │   • Stock levels    │   • Carrier integration    │
│   • Order history    │   • Reservations    │   • Rate calculation       │
│   • Returns/refunds  │   • Reorder alerts  │   • Tracking               │
│   • Order events     │   • Warehouse sync  │   • Delivery scheduling    │
│   Team: Orders       │   Team: Inventory   │   Team: Logistics          │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                          FINANCIAL DOMAIN                                │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│      PAYMENTS       │       BILLING       │        TAX SERVICE         │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Payment gateway  │   • Invoice gen     │   • Tax calculation        │
│   • Fraud detection  │   • Subscription    │   • Jurisdiction rules     │
│   • Refund process   │   • Payment terms   │   • Compliance             │
│   • PCI compliance   │   • Revenue recog   │   • Reporting              │
│   Team: Payments     │   Team: Finance     │   Team: Finance            │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
┌─────────────────────────────────────────────────────────────────────────┐
│                        CUSTOMER DOMAIN                                   │
├─────────────────────┬─────────────────────┬────────────────────────────┤
│      IDENTITY       │       PROFILE       │        SUPPORT             │
│   ─────────────────  │   ───────────────   │   ──────────────────────   │
│   • Authentication   │   • User data       │   • Ticket management      │
│   • Authorization    │   • Preferences     │   • Chat support           │
│   • Session mgmt     │   • Order history   │   • Knowledge base         │
│   • SSO integration  │   • Saved items     │   • Customer satisfaction  │
│   Team: Identity     │   Team: Profile     │   Team: Support            │
└─────────────────────┴─────────────────────┴────────────────────────────┘
 
WHY THESE BOUNDARIES:
• Each service = one business capability
• Each service = one team ownership
• Different change velocities respected (Payments vs Catalog)
• Different scaling needs separated (Search vs Orders)
• Data ownership is clear (each service owns its data)

Evolution Not Revolution

Summary: SRP at the Architecture Level

Key Takeaways

•Bounded contexts are SRP at scale — Each context has one cohesive domain model
•Decompose by business capability — Services should represent what the business does, not technical layers
•Watch for distributed monolith patterns — Synchronous chains of calls indicate poor boundaries
•Event-driven design enforces SRP — Asynchronous events decouple services naturally
•Map architecture to team structure — One team per service; Conway's Law is your friend
•Start modular, split later — Over-decomposition upfront creates unnecessary complexity

Module Complete:

Module Complete