Enterprise Application Patterns Reference

Patterns for domain logic, persistence, presentation, and transactions.

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.

AspectGuidance
Use whenThe domain is simple and operations map cleanly to use cases.
Trade-offsDuplication and tangled rules grow as domain complexity increases.
RelatedService Layer, Domain Model

Domain Model

Represent business concepts, rules, and relationships with behavior-rich objects.

AspectGuidance
Use whenComplex rules and interactions benefit from a shared model and language.
Trade-offsMapping, transactions, and model boundaries require more design.
RelatedData Mapper, Repository

Table Module

Use one object to hold the domain logic for all rows in a table or view.

AspectGuidance
Use whenData is naturally tabular and record sets are central to the platform.
Trade-offsComplex object relationships fit poorly.
RelatedTransaction Script, Table Data Gateway

Service Layer

Define the application boundary and coordinate operations, transactions, and responses.

AspectGuidance
Use whenSeveral clients need a stable set of application use cases.
Trade-offsCan become a thin pass-through or absorb domain logic.
RelatedDomain Model, Facade

Table Data Gateway

Centralize SQL and persistence operations for a table or view in one gateway.

AspectGuidance
Use whenTable-shaped data access should be isolated from domain or presentation logic.
Trade-offsJoins and aggregate boundaries can make gateways awkward.
RelatedRow Data Gateway, Table Module

Row Data Gateway

Wrap one database row with fields and persistence operations.

AspectGuidance
Use whenRecords have simple behavior and identity.
Trade-offsPersistence concerns remain coupled to row-shaped objects.
RelatedActive Record, Table Data Gateway

Active Record

Combine a record-shaped domain object with operations that persist it.

AspectGuidance
Use whenCRUD-heavy applications have straightforward domain behavior.
Trade-offsComplex domains, testing, and multiple stores strain the pattern.
RelatedRow Data Gateway, Data Mapper

Data Mapper

Transfer data between independent domain objects and a data source.

AspectGuidance
Use whenThe domain model must remain unaware of persistence.
Trade-offsMapping metadata and change tracking add substantial machinery.
RelatedDomain Model, Repository

Repository

Present persistence as a domain-oriented collection of aggregates.

AspectGuidance
Use whenDomain code needs queries and persistence without storage details.
Trade-offsGeneric repositories can hide useful query capabilities or leak abstractions.
RelatedData Mapper, Specification

Unit of Work

Track loaded and changed objects, then coordinate their writes as one transaction.

AspectGuidance
Use whenSeveral changes must commit consistently and efficiently.
Trade-offsIdentity, ordering, rollback, and long-lived units add complexity.
RelatedIdentity Map, Data Mapper

Identity Map

Ensure each stored identity maps to one in-memory object per unit of work.

AspectGuidance
Use whenRepeated loads must preserve object identity and avoid inconsistent copies.
Trade-offsScope and memory retention must be controlled.
RelatedUnit of Work, Lazy Load

Lazy Load

Defer loading data until a consumer actually needs it.

AspectGuidance
Use whenRelated data is costly and often unused.
Trade-offsHidden I/O causes latency surprises, N+1 queries, or use-after-session failures.
RelatedIdentity Map, Data Mapper

Data Transfer Object

Bundle serializable data for transfer across process or layer boundaries.

AspectGuidance
Use whenRemote calls should be coarse-grained and contracts must not expose domain internals.
Trade-offsMapping and versioning duplicate shapes and maintenance.
RelatedService Layer, Remote Facade

Optimistic Offline Lock

Allow concurrent work, then reject a write if the stored version changed.

AspectGuidance
Use whenConflicts are uncommon and holding database locks is impractical.
Trade-offsUsers need conflict handling and retries can repeat work.
RelatedUnit of Work, Pessimistic Offline Lock

Model View Controller

Separate domain state, its visual representation, and input coordination.

AspectGuidance
Use whenSeveral presentations or interactions share a model.
Trade-offsResponsibilities and event flow are often interpreted inconsistently.
RelatedFront Controller, Template View

Page Controller

Use one controller for a page, route, or closely related action.

AspectGuidance
Use whenRequest behavior is mostly page-specific.
Trade-offsShared policy and duplicated flow spread across controllers.
RelatedFront Controller, Template View

Front Controller

Send requests through one handler for shared policy and dispatch.

AspectGuidance
Use whenAuthentication, localization, logging, and routing should be consistent.
Trade-offsThe entry point can become a bottleneck or oversized coordinator.
RelatedPage Controller, Application Controller

Template View

Render output by combining a template with supplied data.

AspectGuidance
Use whenMostly textual responses need designer-friendly presentation.
Trade-offsBusiness logic can leak into templates and escaping must be reliable.
RelatedModel View Controller, Data Transfer Object

Application Controller

Centralize application flow and screen or command selection.

AspectGuidance
Use whenNavigation depends on state and is reused across handlers.
Trade-offsA single controller can grow into a hard-to-change state machine.
RelatedFront Controller, State

Description

Patterns for domain logic, persistence, presentation, and transactions.

References

Similar or alternative tools

Don't forget to set a bookmark for tool.io!
Privacy | Imprint | Cookies