05 — Library · 63 patterns
Design patterns an architect reaches for, each with when to use it, a drawing, and the capabilities it helps build.
Showing 9 of 63 patterns
Make each class a mirror of one table, with fields named like its columns and find and save methods of its own, so simple applications get persistence with almost no ceremony.
When · When objects map one-to-one to tables and the logic is light; as rules grow, mixing them with persistence makes both harder to test, which is the point to move to a data mapper.
Reference ↗related DP-570DP-540
A cluster of domain objects treated as one unit for changes, with a single root that enforces its invariants, so consistency rules live in one place and transactions have a natural size.
When · When business rules span several objects that must change together; costs careful boundary sizing, since aggregates that are too large serialize everything and too small cannot enforce the rule.
Reference ↗related DP-210DP-230DP-260
A translation layer between your model and an external or legacy system's model, so foreign concepts and quirks are converted at the boundary instead of leaking into your core.
When · Integrating with a system whose model you do not control and do not want to inherit; costs a mapping layer that must evolve with both sides.
Reference ↗related DP-190DP-210
A single entry point in front of many backend services that handles routing, authentication, rate limits and protocol translation, so each service does not reimplement the edge.
When · As soon as more than a handful of services face external clients; costs a component that can become a bottleneck or a dumping ground for business logic if left unguarded.
Reference ↗related DP-040DP-120DP-360
Capture each significant decision as a short, dated document stating the context, the options, the choice and its consequences, kept next to the code so the reasoning survives the people who made it.
When · Every project with more than one architect or a lifespan over a year; costs a few paragraphs per decision and the habit of writing them before the decision calcifies.
Reference ↗related DP-510DP-490
Give each client type (web, mobile, partner) its own thin backend that shapes and aggregates data for that experience, instead of one general-purpose API that serves everyone poorly.
When · When clients differ enough that one API shape forces chatty calls or over-fetching; costs one more deployable per client and duplicated aggregation logic to keep honest.
Reference ↗related DP-110DP-150
Run two identical production environments, deploy to the idle one, verify it, then switch traffic over in one move, keeping the old environment ready for an instant rollback.
When · Releases where downtime or a slow rollback is unacceptable; costs double the infrastructure during the switch and a plan for database changes that both versions must tolerate.
Reference ↗related DP-380DP-400
Draw an explicit boundary inside which a domain model and its language are consistent, and accept that the same word ("customer", "order") can legitimately mean different things in different contexts.
When · When one enterprise-wide model keeps collapsing under conflicting definitions; costs explicit contracts and translation between contexts rather than one shared schema.
Reference ↗related DP-200DP-220DP-240
Partition a system's resources (thread pools, connections, instances) by consumer or dependency, so one misbehaving tenant or slow downstream exhausts only its own compartment and the rest keep serving.
When · When one noisy workload or dependency can starve everything else; costs idle capacity in each compartment and a sizing decision per partition.
Reference ↗related DP-010DP-040
The application checks a cache first, loads from the system of record on a miss, and writes the result back into the cache, keeping the cache a disposable copy rather than a second source of truth.
When · Read-heavy data that tolerates brief staleness; costs an invalidation strategy, and gets dangerous when the cache quietly becomes the only place a value lives.
Reference ↗related DP-090
Send a small slice of real traffic to the new version, watch its error rate and latency against the old one, and widen the slice only while the signals stay healthy.
When · When production is the only environment that reveals the problem; costs traffic-splitting infrastructure, comparable metrics, and automated rollback when the canary fails.
Reference ↗related DP-370DP-390DP-470
Read a database's transaction log and stream each insert, update and delete as an event, so downstream systems follow the source without batch extracts or application changes.
When · Feeding analytics, caches or search from a system you cannot modify; costs log access on the source, schema-change handling, and events that describe rows rather than business meaning.
Reference ↗related DP-290DP-310DP-330
Wrap a call to a remote dependency in a switch that opens after repeated failures, so callers fail fast and the struggling dependency gets room to recover instead of a stampede.
When · When a slow or failing downstream service would otherwise tie up threads and cascade; costs a fallback path and tuned thresholds.
Reference ↗related DP-020
Store a large payload in shared storage and pass only a reference through the messaging system, so brokers stay fast and message size limits stop shaping the design.
When · Documents, images or bulk records moving through an event pipeline; costs a storage lifecycle for the payloads and a consumer that knows how to redeem the reference.
Reference ↗related DP-160DP-130
Several identical workers pull from the same queue, so throughput scales by adding workers and a failed worker's message is simply picked up by another.
When · Independent units of work that can run in any order; costs idempotent processing and, where ordering matters, partitioning so related messages land on one consumer.
Reference ↗related DP-060DP-180
Inspect each message and send it to the right destination based on its content, so senders do not need to know which of several systems owns a given case.
When · When the same message type is handled by different systems depending on region, product line or customer segment; costs routing rules that need an owner and a test suite.
Reference ↗related DP-130DP-170
Separate the model that handles writes from the models that serve reads, so each can be shaped and scaled for its job instead of one schema compromising for both.
When · When read and write workloads diverge sharply or reads need many denormalized views; costs eventual consistency between the two sides and more moving parts to operate.
Reference ↗related DP-260DP-090DP-300
Put the translation between domain objects and database tables in dedicated mapper classes, so the domain is shaped by the business and the schema by storage, and a change to one does not ripple into the other.
When · When the domain model and the schema differ enough that one cannot simply mirror the other; costs mapping code or an object-relational mapper to configure and learn.
Reference ↗related DP-580DP-550DP-530
Treat analytical data as products owned by the domains that know it, served on a shared self-service platform under federated governance, instead of one central team owning every pipeline.
When · Large organizations where the central data team is the bottleneck; costs real ownership in each domain and a platform good enough that teams do not each build their own.
Reference ↗related DP-330DP-210DP-480
Carry the data a remote call needs in one plain, serializable object shaped for the wire, so a client gets everything for a screen in a single round trip and internal objects never leak across the boundary.
When · At process and service boundaries; costs mapping between internal objects and transfer shapes, and is overkill for calls inside one process.
Reference ↗related DP-600DP-120
Propagate a trace id across every hop of a request and record timed spans in each service, so one slow user action can be followed through the whole system instead of guessed at from separate logs.
When · Any request that crosses more than two services; costs instrumentation in every service and a backend to store and query traces, with sampling once volume grows.
Reference ↗related DP-460DP-420
Record things that happened in the business ("Order Placed", "Invoice Paid") as first-class, named, immutable facts, so other parts of the system react to them rather than polling state.
When · When side effects pile up inside commands or other teams need to know what happened; costs naming discipline and a decision about which events are internal and which are published contracts.
Reference ↗related DP-130DP-220DP-260
Represent the business as objects whose methods enforce its rules on their own state, so a policy such as "an order over the credit limit needs approval" lives in one place and reads the way the business says it.
When · When the business logic is rich and keeps changing; costs a mapping layer to the database and a team that models well, which plain record-keeping does not need.
Persist every change as an appended event and rebuild current state by replaying them, so the full history is the source of truth and any past state can be reconstructed.
When · When audit, temporal queries or replay matter more than simplicity; costs event versioning, snapshotting for performance, and a learning curve the whole team pays.
Reference ↗related DP-270DP-230DP-220
Separate deploying code from releasing a feature by wrapping it in a runtime switch, so unfinished work can ship dark and a bad feature can be turned off without a redeploy.
When · Trunk-based development and gradual rollouts; costs flag hygiene, since every flag left behind is a branch in production that nobody tests.
Reference ↗related DP-380DP-370
Delegate authentication to a trusted identity provider and accept its signed tokens, so applications never handle passwords and users sign in once across many systems.
When · Any application with users who already have a corporate or social identity; costs a dependency on the provider's availability and careful validation of the tokens it issues.
Reference ↗related DP-340DP-110
Express architectural qualities (dependency direction, latency budgets, coupling limits) as automated checks that run in the pipeline, so the architecture is guarded continuously rather than reviewed once.
When · When review boards cannot keep up with the rate of change; costs choosing a few measurable qualities and accepting that the unmeasured ones still need a human.
Reference ↗related DP-500DP-240
Wrap each external system or awkward API (a payment provider, a mainframe interface) in one object that speaks the application's language, so the rest of the code never handles the outside protocol and the gateway can be swapped for a stub in tests.
When · For every external resource the application calls; costs one more class per dependency, which is cheap compared with protocol details scattered through the code.
Reference ↗related DP-200DP-250
Keep the domain logic in the center and reach the outside world (databases, queues, UIs, other services) only through ports and adapters, so infrastructure can be swapped or faked without touching the core.
When · When business logic is worth testing in isolation and infrastructure choices may change; costs more interfaces and indirection than a simple CRUD application needs.
Reference ↗related DP-240DP-200
A consumer records the ids of messages it has already processed and ignores repeats, so at-least-once delivery does not create duplicate orders, payments or notifications.
When · Any consumer behind a broker that may redeliver; costs a deduplication store with a retention window and a message id that producers assign consistently.
Reference ↗related DP-100DP-290DP-020
Never modify a running server or image; every change builds a new artifact that replaces the old one, so what runs in production is exactly what was built and tested.
When · Containers, machine images and anything that can be rebuilt from source; costs a fast build pipeline and giving up the habit of fixing things by hand on the box.
Reference ↗related DP-410DP-370DP-440
Declare networks, compute, storage and permissions in version-controlled files and apply them with a tool, so environments are reproducible, reviewable and diffable like any other code.
When · Every cloud environment that will exist longer than a day; costs state management, a review process for infrastructure changes, and resisting the console when it is faster.
Reference ↗related DP-400DP-350
Run internal projects the way healthy open-source projects run: visible repositories, documented contribution paths, and maintainers who review pull requests from any team.
When · When shared components are blocked on one team's backlog; costs maintainer time for review and the cultural shift from "ask them" to "send a change".
Reference ↗related DP-480DP-500
Land raw data unchanged, refine it into cleaned and conformed tables, then publish curated, business-ready sets, so each layer has a known quality level and lineage back to the source.
When · Building an analytics platform on open table formats over object storage; costs storage for every layer and discipline about which layer consumers are allowed to read.
Reference ↗related DP-320DP-300
Split a user interface into the model that holds the data and rules, views that present it, and controllers that turn user input into actions, so presentation can change without touching the logic underneath.
When · For any interface with real behavior; most web frameworks impose a version of it, and the cost is keeping logic out of views and controllers in practice.
Reference ↗related DP-520DP-120
One deployable unit built from modules with enforced boundaries and explicit interfaces, keeping the operational simplicity of a monolith while preserving the option to extract a service later.
When · Small to mid-sized teams who want clean boundaries without distributed-systems overhead; costs tooling to enforce module boundaries, since a monolith with no fences is just a big ball.
Reference ↗related DP-210DP-250
Let users edit freely without holding locks, record a version with each record, and refuse the save if someone else changed the record since it was read, so long edits never block others and conflicts are caught rather than silently overwritten.
When · When conflicting edits are rare and a business transaction spans several requests; costs a retry or merge experience for the user who loses the race.
Reference ↗related DP-560
Producers publish events to a topic without knowing who listens; any number of subscribers receive each event independently, so adding a consumer never requires changing the producer.
When · When several systems need to react to the same fact; costs event contracts that must be versioned, and the loss of a direct answer to the question "did anyone handle this".
Reference ↗related DP-140DP-230DP-310
Put a queue between producers and a slower consumer so bursts are absorbed and the consumer runs at a steady pace it can sustain, rather than being sized for the peak.
When · When arrival rate is spiky but work can tolerate a short delay; costs a queue to operate and an answer for what happens when the backlog grows faster than it drains.
Reference ↗related DP-050DP-100
Cap how many requests a caller may make in a window and reject or queue the excess with a clear signal, so a shared service protects its own capacity and treats tenants fairly.
When · Any API exposed to many clients or to the public; costs a policy for who gets how much, and clients that know how to back off when told.
Reference ↗related DP-020DP-050DP-110
Copy a primary database to one or more replicas that serve read traffic, so reporting and browse workloads stop competing with writes on the primary.
When · When reads dwarf writes and slightly stale results are acceptable; costs replication lag that the application must account for, especially right after a write.
Reference ↗related DP-070DP-080DP-270
Put a thin remote entry point in front of a detailed object model that answers a whole question in one call (get the order with its lines and shipments) and makes the many small calls locally, so network latency is paid once.
When · Whenever fine-grained objects are exposed across a network; the facade adds no logic of its own, and if it starts deciding things it has become a service layer.
Reference ↗related DP-590DP-520DP-120
Give the domain an object that behaves like an in-memory list of its orders or customers (find the open orders for a customer, add this order) and hide the queries and storage behind it, so domain code never speaks SQL.
When · When domain logic should be testable without a database and storage may change; costs an abstraction that leaks if every query becomes its own repository method.
Reference ↗related DP-570DP-560DP-220
Carry a request over messaging and route the answer back on a reply channel keyed by a correlation id, getting a synchronous-style interaction with the buffering and decoupling of a queue.
When · When a caller needs an answer but the provider should not be called directly; costs correlation bookkeeping, timeouts and a plan for replies that never arrive.
Reference ↗related DP-130DP-150
Repeat a failed call a bounded number of times with growing, jittered delays, so transient faults heal themselves without synchronized retries making them worse.
When · Only for idempotent operations and transient errors; pair with a circuit breaker and a deadline, or retries become a self-inflicted outage.
Reference ↗related DP-010
Run a business transaction across several services as a sequence of local transactions, each with a compensating action that undoes it if a later step fails.
When · When a workflow spans services that cannot share a database transaction; costs compensation logic for every step and acceptance that intermediate states are visible.
Reference ↗related DP-290DP-180DP-230
Broadcast one request to several providers in parallel, then combine their responses into one result, typically with a deadline so a slow participant does not hold the answer hostage.
When · Price checks, searches or availability lookups across many sources; costs aggregation rules for partial results and clear handling of the provider that never answers.
Reference ↗related DP-140DP-120
Keep every event and message schema in a central, versioned registry with compatibility rules enforced at publish time, so a producer cannot silently break its consumers.
When · Any streaming platform with more than one team producing or consuming; costs a registry to run and compatibility rules that make some schema changes slower on purpose.
Reference ↗related DP-130DP-300
Keep credentials, keys and tokens in a dedicated vault that issues them at runtime, rotates them, and logs every access, so no secret lives in source code, config files or a chat thread.
When · From the first deployed service onward; costs a vault to operate and an application bootstrap that can authenticate to it without a secret of its own.
Reference ↗related DP-340DP-410
Put a thin layer of application operations (place order, approve invoice) in front of the domain, each one owning its transaction and security checks, so every client (user interface, API or batch job) calls the same entry points instead of reimplementing the workflow.
When · When several clients drive the same behavior; costs a layer that is pure delegation in simple applications, so keep it thin and put the rules in the domain.
Reference ↗related DP-530DP-540DP-600
Move service-to-service networking (mutual TLS, retries, timeouts, traffic splitting, telemetry) out of application code and into a layer of proxies managed by a control plane.
When · Dozens of services where consistent security and traffic policy matter; costs operational complexity and latency that a small estate will never recoup.
Reference ↗related DP-420DP-340DP-380
Split one logical dataset across several stores by a key, so write volume, storage and hot spots are spread instead of concentrated in a single database.
When · When a single database can no longer hold the data or the write rate; costs cross-shard queries, rebalancing when a key gets hot, and a key choice that is hard to change later.
Reference ↗related DP-090DP-270
Deploy a helper process next to the application in the same unit, handling concerns like proxying, logging or secrets, so those capabilities arrive without being compiled into every service in every language.
When · Polyglot estates where a shared library is impractical; costs one more process per instance and a platform that understands the pairing.
Reference ↗related DP-430DP-450
Define a measurable target for user-facing reliability, and treat the gap between that target and perfection as a budget the team may spend on change; when it is exhausted, reliability work takes priority.
When · When "is it reliable enough" keeps being argued from anecdotes; costs honest measurement and leadership willing to honor the budget when a release date is at stake.
Reference ↗related DP-380DP-450
Put a routing layer in front of a legacy system and move one capability at a time to a new implementation behind it, until the old system serves nothing and can be switched off.
When · Replacing a large system where a single cutover is too risky; costs running both systems for a long time and discipline to finish, since half-strangled systems are the usual outcome.
Reference ↗related DP-200DP-110
Organize most teams around a continuous flow of work for one product or user journey, supported by platform, enabling and complicated-subsystem teams, so ownership and delivery sit in one place.
When · When handoffs between component teams dominate lead time; costs a real platform team and a reorganization that leadership must hold through the awkward period.
Reference ↗related DP-320DP-210DP-490
Emit log events as machine-readable records with consistent fields (timestamp, level, service, trace id, tenant) rather than free text, so logs can be queried and correlated instead of grepped.
When · From the first service onward; costs agreeing on field names across teams and keeping sensitive values out of the fields people are most tempted to log.
Reference ↗related DP-450DP-440
Let a service shed or degrade lower-priority work when it approaches its limits, instead of accepting every request and failing all of them at once.
When · When demand can exceed capacity faster than it can scale; costs an explicit ranking of what to drop first and a degraded mode that still makes sense to users.
Reference ↗related DP-040DP-060
Write each business operation as one procedure that reads what it needs, applies the rules and saves the result from start to finish, so a reader can follow the whole operation in one place.
When · For simple, mostly independent operations; as rules grow and overlap the scripts start copying each other, which is the signal to move toward a domain model.
Reference ↗related DP-530DP-520
Write the business change and the event to publish in the same database transaction, then have a relay publish from the outbox table, so state and messages never disagree.
When · Whenever a service both updates its database and emits events; costs a relay process and an outbox table to prune, which is still cheaper than a lost or phantom event.
Reference ↗related DP-300DP-180DP-280
A set of conventions for services that run well on cloud platforms: configuration from the environment, stateless processes, dependencies declared, logs as streams, disposable instances.
When · Any new service meant for a container or serverless platform; costs externalizing state and configuration, which legacy code written for a single server resists.
Reference ↗related DP-400DP-460DP-350
Track every object a business operation reads, creates, changes or deletes, and write all of it to the database together at the end, in the right order and in one transaction, so a half-finished operation never reaches storage.
When · When an operation touches several records that must change together; most object-relational mappers provide one, and the cost is understanding when it actually flushes.
Reference ↗related DP-550DP-570DP-610
Grant no access based on network location; every request is authenticated, authorized and encrypted against the identity of the user and device, with policy evaluated continuously rather than once at login.
When · Hybrid workforces, cloud estates and any system where the perimeter no longer exists; costs strong identity everywhere first, and a long migration from network-based controls.
Reference ↗related DP-360DP-430DP-350