Architectural Patterns Comparison

​

Pattern Categories

1. Internal Patterns - How code is organized within a service or application
   • N-Tier Architecture
   • Hexagonal Architecture (Ports & Adapters)
   • Clean Architecture
   • Onion Architecture
2. External Patterns - How services are distributed and communicate
   • Monolithic Architecture
   • Modular Monolith
   • Microservices Architecture
   • Event-Driven Architecture

​

Internal Architectural Patterns

​

N-Tier Architecture

​

Design Justification

​

Pros

• Extremely easy to understand and learn
• Most developers are already familiar with the pattern
• Minimal cognitive overhead for new team members
• Clear separation: UI code in presentation, business rules in BLL, database code in DAL

• Quick to set up and start building
• Minimal architectural overhead
• Straightforward data flow from top to bottom
• Works well for CRUD-heavy applications

• Extensive tooling support (Visual Studio, IntelliJ, etc.)
• Many frameworks designed around this pattern (ASP.NET, Spring MVC)
• Large ecosystem of tutorials and examples
• Well-documented best practices

• Easy to assign work based on technical skills
• Frontend developers work in presentation tier
• Backend developers work in business logic tier
• Database specialists work in data access tier

​

Cons

• Business logic directly depends on data access layer
• Changing databases requires modifying business logic
• Framework dependencies leak into business code
• Hard to test business rules in isolation

// Business logic tightly coupled to Supabase
export class WorkspaceService {
  async createWorkspace(name: string) {
    // PROBLEM: Business logic knows about database implementation
    const { data } = await supabase.from('workspaces').insert({ name });
    return data;
  }
}

• Business logic can’t be tested without database
• Tests are slow (require database setup/teardown)
• Tests are fragile (break when database changes)
• Mocking is complex and brittle

• Business logic married to specific ORM or framework
• Difficult to swap technologies
• Framework upgrades can require business logic changes
• Vendor lock-in becomes a serious risk

• Database concerns leak into business logic (SQL, transactions)
• Business logic becomes aware of persistence details
• Domain models often have framework annotations
• Violates Single Responsibility Principle

• Business rules scattered across multiple layers
• Complex domain logic doesn’t fit well in BLL tier
• Validation logic duplicated across layers
• No clear place for domain concepts

​

When to Use

​

When to Avoid

​

Hexagonal Architecture (Ports & Adapters)

​

Design Justification

​

Pros

• Business rules have zero infrastructure dependencies
• No database, no frameworks, no external services
• Core logic expresses business concepts directly
• Easy to understand business rules without technical noise

// Pure domain entity - no infrastructure dependencies
export class Workspace {
  static create(name: string, ownerId: string): Workspace {
    if (name.length < 3 || name.length > 50) {
      throw new DomainError('Workspace name must be 3-50 characters');
    }
    return new Workspace(generateId(), name, ownerId, true, new Date());
  }

  archive(): void {
    if (!this._isActive) {
      throw new DomainError('Workspace is already archived');
    }
    this._isActive = false;
  }
}

• Domain logic tested in isolation without infrastructure
• Tests run in milliseconds (no database, no network)
• Tests are reliable (no external dependencies)
• Easy to write comprehensive test suites

// Test runs instantly, no infrastructure needed
describe('Workspace', () => {
  it('enforces name length business rule', () => {
    expect(() => Workspace.create('ab', 'owner-123'))
      .toThrow('Workspace name must be 3-50 characters');
  });
});

• Infrastructure implemented as pluggable adapters
• Swap Supabase for Prisma without touching business logic
• Change from REST to GraphQL without domain changes
• Framework upgrades don’t affect core business rules

• Domain core focuses purely on business rules
• Adapters handle technical concerns
• Ports define clear contracts
• Each layer has a single, well-defined responsibility

• Easy to write tests before implementation
• Fast feedback loop encourages TDD practices
• Can develop business logic without infrastructure setup
• Reduces time to first working test

• Natural fit for DDD patterns (entities, value objects, aggregates)
• Business logic expressed in ubiquitous language
• Clear boundaries between domain and infrastructure
• Supports rich domain models

​

Cons

• More moving parts than N-Tier
• Requires understanding of dependency inversion
• Team needs training on hexagonal concepts
• Harder for junior developers initially

• Need to write ports (interfaces) and adapters
• Mapping between domain models and database models
• Dependency injection configuration
• More files and folders to manage

// Domain model
class Workspace { ... }

// Port (interface)
interface WorkspaceRepository { ... }

// Adapter implementation
class SupabaseWorkspaceRepository implements WorkspaceRepository { ... }

// Mapping logic
private toDomain(row: any): Workspace { ... }
private toDatabase(workspace: Workspace): any { ... }

// More code than just `await supabase.from('workspaces').insert(...)`

• Unnecessary complexity for basic data management
• Slows down development of trivial features
• Mapping overhead adds no value for simple cases
• May frustrate team working on straightforward tasks

• Easy to bypass abstractions and couple to infrastructure
• Needs code reviews to enforce boundaries
• Developers may take shortcuts under pressure
• Degradation is gradual and hard to detect

​

When to Use

​

When to Avoid

​

Clean Architecture

​

Design Justification

​

Pros

• Four clearly defined layers with specific purposes
• Enterprise Business Rules (entities) - core domain
• Application Business Rules (use cases) - application workflows
• Interface Adapters (controllers) - translation layer
• Frameworks & Drivers (infrastructure) - external tools

• Dependencies can only point inward, never outward
• Inner layers know nothing about outer layers
• Violations are easy to detect
• Architectural integrity is maintainable

• Application workflows explicitly modeled
• Clear boundary between domain and application logic
• Use cases are testable application-level operations
• Business processes well-documented in code

// Use case clearly expresses application workflow
export class CreateWorkspaceUseCase {
  constructor(
    private readonly repository: WorkspaceRepository,
    private readonly eventPublisher: EventPublisher
  ) {}

  async execute(command: CreateWorkspaceCommand): Promise<Workspace> {
    // 1. Create domain entity (domain logic)
    const workspace = Workspace.create(command.name, command.ownerId);

    // 2. Persist (infrastructure)
    await this.repository.save(workspace);

    // 3. Publish event (infrastructure)
    await this.eventPublisher.publish(new WorkspaceCreatedEvent(workspace));

    return workspace;
  }
}

• Core business logic has zero framework dependencies
• Can upgrade frameworks without touching entities or use cases
• Frameworks become implementation details
• Reduces framework lock-in risks

​

Cons

• Four layers vs hexagonal’s simpler structure
• Can feel over-engineered for some applications
• More navigation between files and folders
• Steeper learning curve

• Developers may struggle with entity vs use case logic
• Business rules can end up in wrong layer
• Requires deep understanding of DDD concepts
• Guidelines needed to maintain clear boundaries

• Each application workflow becomes a separate use case
• Can lead to many small, similar classes
• Folder structure can become overwhelming
• Feels like boilerplate for simple operations

​

When to Use

​

When to Avoid

​

Onion Architecture

​

Design Justification

​

Pros & Cons

• Visual metaphor (onion layers) is intuitive
• Slightly simpler than Clean (fewer prescribed layers)
• Emphasizes domain services as a separate layer
• Popular in .NET community

​

External Architectural Patterns

​

Monolithic Architecture

​

Design Justification

​

Pros

• Single codebase, single repository
• Single deployment artifact
• Simple development environment setup
• Easy to reason about the entire system

• All code changes happen in one place
• No cross-service coordination needed
• Straightforward debugging (single process)
• IDE works well with single codebase

• Deploy one artifact to production
• Atomic deployments (all or nothing)
• No service orchestration needed
• Rollback is straightforward

• In-process function calls (fast)
• No network overhead between modules
• Single database connection pool
• No serialization/deserialization overhead

• Spin up entire application locally
• Integration tests are straightforward
• No need to mock external services
• Complete system available for testing

​

Cons

• Must scale entire application as a unit
• Can’t scale individual features independently
• Wasteful resource allocation
• Expensive at high scale

// Problem: Even if only the reporting module needs more resources,
// we must scale the entire monolith

// Monolith running on server:
// - User authentication (low load)
// - CRUD operations (low load)
// - Report generation (HIGH load) ← Only this needs scaling
// - Admin panel (low load)

// Must scale everything to handle report generation load
// This scales authentication, CRUD, and admin unnecessarily

• Modules easily become interdependent
• Changes ripple across the codebase
• Hard to isolate features
• Difficult to enforce module boundaries

• Large codebase slows down IDE
• Long build times
• Merge conflicts increase with team size
• Difficult to parallelize work across teams

• Any change requires deploying entire application
• Small bug fix carries high risk
• Downtime affects all features
• Rollback affects entire system

• Entire application must use same technology stack
• Can’t adopt new technologies incrementally
• Framework upgrades affect entire application
• Limited flexibility in technology choices

• Difficult to divide work across multiple teams
• High coordination overhead
• Merge conflicts increase
• Conway’s Law: Organization mirrors monolith structure

​

When to Use

​

When to Avoid

​

Modular Monolith

​

Design Justification

​

Pros

• Single deployment unit (simple operations)
• Clear module boundaries (organizational clarity)
• Shared infrastructure (reduced duplication)
• Easier than microservices to operate

• Teams can own modules independently
• Reduced coordination overhead
• Clear ownership boundaries
• Parallel development possible

• Modules communicate through well-defined interfaces
• Can enforce boundaries programmatically
• No network overhead
• Easier to refactor than microservices

• Modules can be extracted as services later
• Boundaries already defined
• Incremental migration possible
• Low-risk evolution strategy

// apps/web/src/ - Modular organization
apps/web/src/
├── app/[locale]/(dashboard)/[wsId]/
│   ├── finance/           # Finance module
│   │   ├── transactions/
│   │   ├── reports/
│   │   └── _components/   # Finance-specific components
│   ├── calendar/          # Calendar module
│   │   ├── events/
│   │   └── _components/   # Calendar-specific components
│   └── tasks/             # Tasks module
│       ├── boards/
│       └── _components/   # Task-specific components

• Reuse common utilities easily
• Shared authentication, logging, etc.
• No code duplication across modules
• Centralized configuration

​

Cons

• Easy to create cross-module dependencies
• Boundaries are convention-based, not enforced
• Gradual degradation without governance
• Need automated tools to detect violations

• Can’t scale individual modules
• All modules deployed together
• Resource allocation is coarse-grained
• Same scaling limitations as monolith

• All modules use same database
• Schema coupling between modules
• Difficult to optimize per-module data access
• Database becomes single point of contention

• Module failure can affect other modules
• Shared resources (memory, CPU) create contention
• Memory leak in one module affects all
• Less fault isolation than microservices

​

When to Use

​

When to Avoid

​

Microservices Architecture

​

Design Justification

​

Pros

• Deploy services independently without coordination
• Scale services based on individual needs
• Deploy multiple times per day per service
• Reduced deployment risk (only one service affected)

// Different services scale independently
const scaling = {
  web: { min: 2, max: 100 },      // High traffic, needs scaling
  finance: { min: 1, max: 10 },   // Moderate traffic
  calendar: { min: 1, max: 5 },   // Low traffic
  admin: { min: 1, max: 2 }       // Very low traffic
};

• Teams own services end-to-end (“you build it, you run it”)
• Parallel development across teams
• Reduced coordination overhead
• Clear ownership and accountability

• Each service can use different technology stack
• Choose best tool for each job
• Experiment with new technologies in isolation
• Incremental technology adoption

// Different services, different technologies
const services = {
  web: { language: 'TypeScript', framework: 'Next.js' },
  ml: { language: 'Python', framework: 'FastAPI' },
  realtime: { language: 'Go', framework: 'Gin' },
  batch: { language: 'Rust', framework: 'Actix' }
};

• Service failure doesn’t bring down entire system
• Blast radius is limited to single service
• Other services continue operating
• System degrades gracefully

• Each service is small and focused
• New developers can understand one service quickly
• Cognitive load is reduced
• Domain complexity is bounded

​

Cons

• Need service discovery, API gateway, load balancers
• Distributed logging, tracing, and monitoring essential
• Complex deployment pipelines
• Requires mature DevOps practices

• Network latency and unreliability
• Debugging is harder (distributed tracing needed)
• Performance tuning is complex
• Testing end-to-end is difficult

• Each service has its own database
• No distributed transactions (must use sagas)
• Eventual consistency instead of strong consistency
• Complex queries across services are difficult

// Complex workflow spanning multiple services
async function createWorkspaceWithResources(data: WorkspaceData) {
  // 1. Create workspace (Web Service)
  const workspace = await webService.createWorkspace(data);

  // 2. Setup finance (Finance Service)
  // Problem: What if this fails? Need saga pattern
  await financeService.setupAccount(workspace.id);

  // 3. Create calendar (Calendar Service)
  // Problem: What if this fails? How to rollback?
  await calendarService.createCalendar(workspace.id);

  // Need complex saga orchestration for rollback
}

• More servers/containers to run
• More databases to maintain
• More monitoring and logging infrastructure
• Higher cloud bills

• Teams must be autonomous and skilled
• Need strong DevOps culture
• Requires discipline to maintain service boundaries
• Not suitable for inexperienced teams

• Must maintain backward compatibility
• Breaking changes require careful coordination
• Versioning strategy is essential
• Contract testing is mandatory

​

When to Use

​

When to Avoid

​

Event-Driven Architecture

​

Design Justification

​

Pros

• Producers don’t know about consumers
• Consumers don’t know about producers
• Services can be added/removed without changes
• Natural extensibility

// Producer: Publishes event, unaware of consumers
await trigger.event({
  name: 'workspace.created',
  payload: { workspaceId, ownerId, name }
});

// Consumer 1: Sends welcome email (can add without changing producer)
client.defineJob({
  id: 'send-welcome-email',
  trigger: eventTrigger({ name: 'workspace.created' }),
  run: async (payload) => await sendEmail(payload.ownerId)
});

// Consumer 2: Setup analytics (added later, no producer change)
client.defineJob({
  id: 'setup-analytics',
  trigger: eventTrigger({ name: 'workspace.created' }),
  run: async (payload) => await trackWorkspace(payload.workspaceId)
});

// Consumer 3: AI onboarding (added even later, still no producer change)
client.defineJob({
  id: 'ai-onboarding',
  trigger: eventTrigger({ name: 'workspace.created' }),
  run: async (payload) => await setupAI(payload.workspaceId)
});

• Broker acts as buffer for failures
• If consumer is down, events are persisted
• Automatic retry mechanisms
• Temporal decoupling (producer doesn’t wait)

• Producers don’t block on consumers
• Fast response times for users
• Long-running operations don’t slow down requests
• Better resource utilization

• Complete history of events
• Can replay events for debugging
• Natural audit log
• Time-travel debugging possible

• Add new features by adding new consumers
• No changes to existing services
• Supports A/B testing (run old and new consumers in parallel)
• Safe experimentation

​

Cons

• No immediate consistency guarantees
• System state converges over time
• Complex to reason about for developers
• Debugging race conditions is hard

// User creates workspace
await webService.createWorkspace(data);

// User immediately tries to access analytics
// Problem: Analytics consumer may not have processed event yet
const analytics = await analyticsService.getWorkspaceAnalytics(workspaceId);
// May return null because event hasn't been processed yet!

• Need to manage event broker infrastructure
• Event schema versioning is critical
• Debugging distributed event flows is difficult
• Monitoring and observability are essential

• Breaking changes to events affect all consumers
• Need careful versioning strategy
• Documentation of event schemas is critical
• Contract testing is mandatory

• Can’t return result from consumer to producer
• Must poll or use separate response events
• Complex request-response patterns
• Not suitable for all workflows

• Cascading events can amplify load
• Event loops are possible
• Need circuit breakers and rate limiting
• Monitoring for event accumulation essential

​

When to Use

​

When to Avoid

​

Comprehensive Comparison Matrix

​

Decision Framework

​

Choosing Internal Patterns

​

Choosing External Patterns

​

Tuturuuu’s Architectural Decisions

​

External Architecture: Microservices + Event-Driven

• Multiple teams working on different domains (AI, Finance, Calendar)
• Need independent deployment and scaling
• Want technology flexibility per service
• High availability requirements

• Microservices for organizational scalability and independent deployment
• Event-Driven for decoupling and resilience

​

Internal Architecture: Hexagonal (Within Each Service)

• Complex business logic needs protection
• High test coverage requirements
• Long-term maintainability is critical
• May need to swap infrastructure (Supabase → another provider)

​

Frontend: Modular Monolith

• Single deployment simplifies frontend operations
• Clear module boundaries support team scalability
• Don’t need independent frontend deployment yet
• Migration path to micro-frontends if needed

​

Related Documentation

• Layering Patterns - Detailed comparison of N-Tier vs Hexagonal
• Architectural Decisions - Core architectural choices in Tuturuuu
• Hexagonal Architecture - Implementation details
• Microservices Patterns - Service boundaries and communication
• Event-Driven Architecture - Event streaming patterns