Domain-Driven Design & Application Patterns

A bounded context is a boundary around a part of a system where a specific model and its terms have one exact meaning. Outside that boundary, the same word can mean something completely different.

A context map is a diagram showing all the bounded contexts in a system, how they connect, which one leads (upstream) vs follows (downstream), and which teams own each one.

An Anti-Corruption Layer is a translation wall between your code and someone else's system, so their messy or different data model doesn't leak into and pollute your own model.

A domain vision statement is a short written description of the core domain, its value, and why it will make the product win — a compass for what's most important to build well.

This is Event Storming - a workshop where people from business and tech stand at a wall and write domain events (things that happened) on orange sticky notes in time order, to quickly build a shared picture of how a system or business process really works.

An aggregate root is the single object outside code may touch inside a related cluster. Everything else is reached through it. Other code keeps just its ID, not a direct pointer, so it can't reach in and break the rules.

An application service coordinates a use case — starts transactions, checks permissions, calls objects, converts data — without deciding business rules. A domain service holds business rules that don't fit one entity, like a rule spanning two accounts.

A domain event is a note that something meaningful already happened in the business, e.g. 'OrderShipped'. It's named in the past tense because it records a fact that occurred, not a request asking for something to happen.

A Domain Service holds business logic that doesn't fit on one specific object. You use one when an operation needs several objects together, or is really an action rather than a 'thing' - like transferring money between two accounts.

An Entity is something with its own identity that stays the same over time even if its details change — like a person has one ID for life. A Value Object has no identity of its own; it's just described by its data, so two Value Objects with the same data are treated as equal and interchangeable.

The model isn't a picture you draw once and forget — it's the actual blueprint that the code, database, and APIs are built from and kept in sync with, so it stays accurate and useful as the system evolves.

An internal DSL is written using the normal syntax of an existing programming language, just arranged to read like a mini-language for one job (e.g. a Kotlin build script). An external DSL has its own custom syntax and needs its own parser to be understood, like SQL or a regular expression.

MDA is a way of building software by first drawing a model of what the system does, ignoring the technology, then turning that model into one tied to a specific technology (like Java or a database), and finally generating code from it.

Forward engineering writes the model first, then a tool generates code from it. Reverse engineering starts from existing code and builds or updates a model to describe it. Same goal—keep model and code matching—different starting point.

Model-to-text turns a model into plain text, like source code, mostly a one-way trip. Model-to-model turns one structured model into another structured model, so it stays machine-readable and can be transformed again.

Active Record is a design where one class both holds the data fields of a database row (like name, price) and has methods to save, load, and delete itself from that row's table.

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.