Enterprise Application Patterns Reference
Intent, fit, trade-offs, and relationships for enterprise application architecture patterns.
Updated 2026-07-22
Transaction Script
Organize business logic by operation, with each procedure handling one request.
| Aspect | Guidance |
|---|---|
| Use when | The domain is simple and operations map cleanly to use cases. |
| Trade-offs | Duplication and tangled rules grow as domain complexity increases. |
| Related | Service Layer, Domain Model |
Domain Model
Represent business concepts, rules, and relationships with behavior-rich objects.
| Aspect | Guidance |
|---|---|
| Use when | Complex rules and interactions benefit from a shared model and language. |
| Trade-offs | Mapping, transactions, and model boundaries require more design. |
| Related | Data Mapper, Repository |
Table Module
Use one object to hold the domain logic for all rows in a table or view.
| Aspect | Guidance |
|---|---|
| Use when | Data is naturally tabular and record sets are central to the platform. |
| Trade-offs | Complex object relationships fit poorly. |
| Related | Transaction Script, Table Data Gateway |
Service Layer
Define the application boundary and coordinate operations, transactions, and responses.
| Aspect | Guidance |
|---|---|
| Use when | Several clients need a stable set of application use cases. |
| Trade-offs | Can become a thin pass-through or absorb domain logic. |
| Related | Domain Model, Facade |
Table Data Gateway
Centralize SQL and persistence operations for a table or view in one gateway.
| Aspect | Guidance |
|---|---|
| Use when | Table-shaped data access should be isolated from domain or presentation logic. |
| Trade-offs | Joins and aggregate boundaries can make gateways awkward. |
| Related | Row Data Gateway, Table Module |
Row Data Gateway
Wrap one database row with fields and persistence operations.
| Aspect | Guidance |
|---|---|
| Use when | Records have simple behavior and identity. |
| Trade-offs | Persistence concerns remain coupled to row-shaped objects. |
| Related | Active Record, Table Data Gateway |
Active Record
Combine a record-shaped domain object with operations that persist it.
| Aspect | Guidance |
|---|---|
| Use when | CRUD-heavy applications have straightforward domain behavior. |
| Trade-offs | Complex domains, testing, and multiple stores strain the pattern. |
| Related | Row Data Gateway, Data Mapper |
Data Mapper
Transfer data between independent domain objects and a data source.
| Aspect | Guidance |
|---|---|
| Use when | The domain model must remain unaware of persistence. |
| Trade-offs | Mapping metadata and change tracking add substantial machinery. |
| Related | Domain Model, Repository |
Repository
Present persistence as a domain-oriented collection of aggregates.
| Aspect | Guidance |
|---|---|
| Use when | Domain code needs queries and persistence without storage details. |
| Trade-offs | Generic repositories can hide useful query capabilities or leak abstractions. |
| Related | Data Mapper, Specification |
Unit of Work
Track loaded and changed objects, then coordinate their writes as one transaction.
| Aspect | Guidance |
|---|---|
| Use when | Several changes must commit consistently and efficiently. |
| Trade-offs | Identity, ordering, rollback, and long-lived units add complexity. |
| Related | Identity Map, Data Mapper |
Identity Map
Ensure each stored identity maps to one in-memory object per unit of work.
| Aspect | Guidance |
|---|---|
| Use when | Repeated loads must preserve object identity and avoid inconsistent copies. |
| Trade-offs | Scope and memory retention must be controlled. |
| Related | Unit of Work, Lazy Load |
Lazy Load
Defer loading data until a consumer actually needs it.
| Aspect | Guidance |
|---|---|
| Use when | Related data is costly and often unused. |
| Trade-offs | Hidden I/O causes latency surprises, N+1 queries, or use-after-session failures. |
| Related | Identity Map, Data Mapper |
Data Transfer Object
Bundle serializable data for transfer across process or layer boundaries.
| Aspect | Guidance |
|---|---|
| Use when | Remote calls should be coarse-grained and contracts must not expose domain internals. |
| Trade-offs | Mapping and versioning duplicate shapes and maintenance. |
| Related | Service Layer, Remote Facade |
Optimistic Offline Lock
Allow concurrent work, then reject a write if the stored version changed.
| Aspect | Guidance |
|---|---|
| Use when | Conflicts are uncommon and holding database locks is impractical. |
| Trade-offs | Users need conflict handling and retries can repeat work. |
| Related | Unit of Work, Pessimistic Offline Lock |
Model View Controller
Separate domain state, its visual representation, and input coordination.
| Aspect | Guidance |
|---|---|
| Use when | Several presentations or interactions share a model. |
| Trade-offs | Responsibilities and event flow are often interpreted inconsistently. |
| Related | Front Controller, Template View |
Page Controller
Use one controller for a page, route, or closely related action.
| Aspect | Guidance |
|---|---|
| Use when | Request behavior is mostly page-specific. |
| Trade-offs | Shared policy and duplicated flow spread across controllers. |
| Related | Front Controller, Template View |
Front Controller
Send requests through one handler for shared policy and dispatch.
| Aspect | Guidance |
|---|---|
| Use when | Authentication, localization, logging, and routing should be consistent. |
| Trade-offs | The entry point can become a bottleneck or oversized coordinator. |
| Related | Page Controller, Application Controller |
Template View
Render output by combining a template with supplied data.
| Aspect | Guidance |
|---|---|
| Use when | Mostly textual responses need designer-friendly presentation. |
| Trade-offs | Business logic can leak into templates and escaping must be reliable. |
| Related | Model View Controller, Data Transfer Object |
Application Controller
Centralize application flow and screen or command selection.
| Aspect | Guidance |
|---|---|
| Use when | Navigation depends on state and is reused across handlers. |
| Trade-offs | A single controller can grow into a hard-to-change state machine. |
| Related | Front Controller, State |