Skip to content

15 — Architectural & Enterprise Patterns

Driving question: How do recurring patterns scale from object collaboration to subsystem and application structure?

Learning objectives

  • Relate Layered, MVC, Microkernel, Pipes-and-Filters, Repository, Unit of Work, and Data Mapper patterns.
  • Separate architectural pattern intent from framework conventions.
  • Analyze transaction/data ownership consequences.
  • Recognize when enterprise patterns become ceremonial complexity.

From objects to systems

Architectural patterns constrain subsystem responsibilities and connectors. Enterprise application patterns often address persistence, transactions, domain logic, presentation, and distribution.

Examples:

  • Layered Architecture — organizes responsibilities by abstraction/service level.
  • MVC — separates model, presentation, and interaction responsibilities.
  • Microkernel/Plugin — supports product variation through extension modules.
  • Repository — exposes collection-like access to domain objects while hiding persistence details.
  • Unit of Work — coordinates changes in a business transaction.
  • Data Mapper — keeps domain objects independent of persistence mapping.

Context first

A pattern from a large transactional enterprise system can be unnecessary in a small immutable service. Pattern transfer must preserve the original forces.

Design / research exercise

Select one popular framework abstraction named after a pattern (Repository, MVC, Observer, etc.). Compare the framework’s actual semantics with the canonical pattern intent.

Suggested reading

  • Martin Fowler, Patterns of Enterprise Application Architecture.
  • POSA literature.