Application Architecture Patterns (PoEAA)

A Transaction Script is one procedure that handles a single business request end to end: it reads input, runs the rules step by step, talks to the database, and returns a result. No shared object model, just a top-to-bottom recipe per action.

A DTO is a plain object built just to carry data across a boundary, like a network call. Services return DTOs instead of internal objects so clients don't depend on internal details that might change, break, or leak sensitive data.

A command tells one system to do something specific, like 'ship this order.' An event announces that something already happened, like 'order shipped,' and anyone can listen. A query just asks for data without changing anything. Each creates a different kind of dependency between sender and receiver.

Lazy Load means you don't fetch data until you actually need it. Instead of loading a whole object graph at once (which can be slow and wasteful), you load the minimum needed now and fetch the rest later, only if code actually asks for it.

Identity Field stores the database primary key inside the object so the mapper always knows which row that object represents, because loading the same row twice can create two different object instances that need to be recognized as the same thing.

A Repository is an object that lets your business code save and fetch domain objects using simple method calls, like a collection, without knowing whether the data lives in a SQL database, a file, or memory.

A Service Layer is a thin layer of methods that sit in front of the business logic. Instead of each screen or API endpoint talking to domain objects and the database directly, it calls one Service Layer method that does the whole job for it.

It's an object that remembers every change you made to your data - new records, edits, deletions - while you work, then writes them all to the database together in one go, instead of saving each change separately.

Row Data Gateway makes one gateway object per database row (so 10,000 rows means up to 10,000 objects), while Table Data Gateway makes one single object for the whole table that you call with row IDs as parameters.

Data Mapper keeps your business objects completely unaware of the database — a separate 'mapper' class does all the saving and loading — so your business logic stays clean and testable, but you now have to write and maintain that extra mapping layer.

Domain Model puts business rules inside objects that represent real concepts, like an Order that knows how to calculate its own total, while Transaction Script keeps rules in separate step-by-step procedures. Pick Domain Model when rules are complex and interact a lot; pick Transaction Script when they're simple.

The Assembler is the piece of code that copies data between a domain object and its DTO, in both directions. It should live in its own small class, not inside the domain object or the web controller, so each side stays focused on its own job.

A point-to-point channel delivers each message to exactly one consumer, even if several are listening — good for work that should happen once. A publish-subscribe channel delivers a copy of each message to every subscriber, good for broadcasting facts to many independent listeners.

When messages travel through queues instead of direct calls, a reply can arrive long after (and out of order from) the request, so you need a shared ID stamped on both to know which reply answers which request.

Lazy initialization checks a flag before loading. A virtual proxy is a stand-in object that loads the real one on first use. A value holder is a small wrapper that loads its value on request. A ghost is a mostly-empty real object that fills itself in when any field is touched.

Foreign Key Mapping stores the parent's ID as a column on the child's table (or an in-memory reference resolved to that column), so 'many' rows point back to 'one' row. The problem is you can't put a real parent ID on the child until the parent has actually been saved and been given one.

This is the N+1 selects problem: one query loads the list, then one extra query per item fetches its related data, because each lazy association is fetched separately the moment it's touched. Fix it by fetching the related data in one batched query up front, not by making everything eager everywhere.

It's called query encapsulation: the Repository hides the actual query logic behind a named method, so callers just say what they want, not how to fetch it, and can't accidentally write unsafe or database-specific queries.

Operation script means the service method itself contains the step-by-step logic for the use case. Domain facade means the service method is thin and mostly just calls rich behavior already living on domain objects. Pick domain facade when the logic is reused or complex; pick operation script when the use case is simple and one-off.

The Service Layer method usually opens one transaction at the start of the use case and commits it at the end, so all the changes it makes either all succeed or all fail together. If it opens too many small transactions, you can end up with half-finished work; if one transaction is too big, it can lock too much data for too long.

It keeps a copy of each object's data from when it was loaded, then compares that copy to the current object right before saving; anything different gets an UPDATE. The identity map makes sure there's only one copy of each record in memory to compare.

An anemic domain model is when your 'domain' objects are just data bags with getters and setters and no real logic, while all the actual business rules live in separate service classes. It looks object-oriented but behaves like plain procedural code.

Most real messaging systems can only promise 'at least once' delivery, so the same message can arrive twice (e.g., after a retry). The receiver has to notice a duplicate itself and skip re-doing the work, or side effects like double-charging happen.

Lazy loading fetches each order's line items only when asked. Looping over 100 orders and asking each one for its items triggers 100 separate database round-trips (plus the original 1 to get the orders) instead of one combined query — that's the classic N+1 problem.

The lazy field needs an active connection/session to fetch its data. By the time rendering happens, that connection is already closed, so trying to load the field fails with an error instead of quietly returning data.

Single Table Inheritance puts every subclass's columns in one wide table with lots of nulls. Class Table Inheritance splits shared and subclass-specific columns into separate tables joined by shared ID. Concrete Table Inheritance gives each subclass its own fully self-contained table, duplicating the shared columns.

A Repository should return plain domain objects, not framework-specific wrappers. If it leaks framework types, callers end up depending on that framework everywhere, which defeats the whole point of hiding persistence details.

It has to insert parent records before child records that reference them, and delete child records before their parents, otherwise the database rejects the write for violating a foreign key rule. The Unit of Work sorts writes to respect those dependencies before sending them.

Table Module has one class per database table, not per row, and it holds the business logic for that table. You pass it a set of rows, like a whole table's worth of data, instead of creating a separate object for each individual record.