Application Architecture Patterns (PoEAA)

When you serialize a database object straight to JSON, its linked objects (like an order's items, and each item's link back to the order) can form a loop the serializer walks forever, or pull in huge amounts of related data no one asked for. A DTO fixes this by only including the exact fields you choose, with no loops and no surprise data.

The serializer walks every field it can see, including lazy ones, so touching a lazy field during serialization either triggers a slow chain of hidden loads (sometimes recursively, pulling in huge amounts of data) or throws if the loading context is already gone. The fix is to convert to a plain response object with only the fields you actually want, before serializing.

The fake in-memory version might behave slightly differently than the real database, like ignoring case or not enforcing uniqueness, so tests pass on the fake but fail for real. Catch it with one shared test suite run against both.

A Repository is where you go to find and fetch objects, like a filing cabinet drawer for one type of thing. The Unit of Work is the assistant that remembers everything you changed across all the drawers and files it all away together at the end.

Active Record assumes one class equals one table, so once a business object is really made of several tables or types, forcing it into a single self-saving class gets messy — you start seeing bloated classes and awkward save-ordering workarounds, which is a sign to switch to a pattern that separates the domain object from its database mapping.

Active Record couples business logic and database access the most, because they're the same class. Data Mapper couples them the least, since the business object never touches SQL. Row Data Gateway and Table Data Gateway sit in between — no business logic lives in them at all, but whatever logic calls them still needs a real or fake gateway to run its tests.

Every DTO means extra classes and mapping code to write and keep in sync, which slows down small changes and adds files to maintain. For a tiny internal tool with one trusted client and a short lifespan, that overhead may not be worth it.

A good filter does one transformation, takes input from a pipe and puts output on the next pipe, and doesn't know or care what's upstream or downstream. Chaining many small ones is flexible and reusable, but adds latency and more places for failures to hide.

Association Table Mapping adds a third table with two foreign key columns, one pointing to each side, so many Students can link to many Courses without duplicating data on either table. Once the relationship needs its own attribute, like an enrollment date, that link table gets a real primary key and becomes a full entity itself.

If a Repository just re-exposes the ORM's own save/find/delete methods, it's extra boilerplate with no real decoupling benefit. Skip it for small, simple apps where the ORM's API is already good enough.

Across a network, every call is slow and can fail on its own, so remote-facing methods should be few, chunky, and do a lot per call — pass whole batches of data instead of tiny get/set calls. In-process calls are cheap, so they can be small and frequent.

It means the same business rule now lives in several places instead of one, so they can quietly drift apart and disagree. The usual fixes are pulling the shared rule out into a single helper or domain method that every service method calls, then deleting the old copies.

If you keep the 'save later' tracker open too long, it piles up memory for every object it ever touched, starts returning old data instead of fresh data, and can accidentally save changes the user made way earlier than expected.

Pick the simplest pattern that fits how complex your business rules and data relationships are today, and how much they're expected to grow — simple CRUD favors Active Record or a gateway, complex evolving domains favor Data Mapper. It's fine to use different patterns in different parts of one system if each part's complexity genuinely differs.

Watch for pain signals — like duplicated rules and tangled functions — before deciding to switch styles, then move gradually, pulling shared rules into small rich objects piece by piece, instead of doing a risky big rewrite of everything at once.

Each service's database can only guarantee atomicity for its own local changes, not across services over a network. A saga breaks the transaction into a sequence of local steps, and if a later step fails, it runs 'undo' actions (compensations) for the steps that already succeeded, instead of a true rollback.

If lots of code paths always need the 'lazy' data anyway, or if the app is highly concurrent, lazy loading adds complexity and race-condition risk without saving much. Two threads racing to load the same not-yet-loaded field can both start loading at once, corrupt the field, or hand back different values.

There's no single right default: pick lazy or eager per association based on how often each screen actually needs it, and for read-heavy endpoints, skip loading full objects altogether and query a flat projection with just the columns that screen displays.

Over years, mapper classes tend to grow messy: they pick up business logic they shouldn't have, DTOs quietly start looking just like the database tables again, and old fields never get cleaned up. Fixing this means regularly auditing mappers for logic that snuck in and removing DTO fields no client actually uses.

One generic Repository shared by every entity forces them all into the same shape of querying and saving, which breaks once some entities need different rules. Teams usually replace it with entity-specific, purpose-built interfaces.

It's defensible when there's only one client and the logic is simple - you avoid writing and maintaining an extra layer for no real benefit. What you give up is a single reuse point if a second client (like an API or batch job) shows up later, so you may need to add it in then.

When you're changing huge numbers of rows at once (bulk jobs), or writing across multiple independent services/databases where one shared transaction isn't possible, the automatic 'track everything then save' approach costs more than it helps - explicit, targeted SQL or separately coordinated writes work better.