Loading...
Glossary of software engineering concepts covered in Three Dots Labs trainings.
Unnecessary difficulty introduced through implementation choices, technology decisions, or misapplied patterns.
A cluster of domain objects that are treated as a single unit for data changes and consistency.
A translation layer between two bounded contexts that protects your domain model from another context's concepts and changes.
Defining the API contract before writing implementation code, then generating servers and clients from the spec.
A component that orchestrates use cases by coordinating domain objects, repositories, and external services.
A delivery guarantee where messages are delivered one or more times, requiring idempotent handling.
The first level of Event Storming. Maps an entire business flow on a timeline using domain events, with no concern for code or implementation.
A boundary within which a particular domain model is defined and consistent.
A coordination pattern where services react to events independently, without a central orchestrator.
A resilience pattern that stops calling a failing service, giving it time to recover before retrying.
An architectural approach that keeps business logic independent of frameworks, databases, and external systems.
A request to change the state of the system, handled by a single handler in a CQRS architecture.
Tests that verify complete business cases through your public API with real infrastructure but mocked external services.
A mechanism that lets multiple instances of a service share the work of processing messages from a topic.
The practice of describing how bounded contexts depend on each other and how teams collaborate across those boundaries.
A unique identifier that tracks a single business operation as it flows across services and messages.
Separating read and write models to optimize each independently.
A central store where all domain events are kept in raw form for replay, analytics, and read model rebuilding.
A software design approach that puts the business domain at the center of your architecture and code.
A separate queue where messages that can't be processed are moved aside for inspection and manual handling.
Passing dependencies to a component from the outside instead of letting it create them internally.
A design principle where high-level modules depend on abstractions, not on low-level implementation details.
A system where multiple services work together, communicating over a network.
Coordinating changes across multiple services so they either all succeed or all get rolled back.
The innermost layer of your application containing pure business logic, free of databases, frameworks, and infrastructure.
Starting development by building the domain layer with in-memory storage, deferring database and infrastructure decisions.
A struct whose only job is carrying data across a boundary, keeping domain types independent of their wire or storage format.
A domain object defined by its identity rather than its attributes.
The inherent difficulty that comes from the problem domain itself. It can't be removed by better engineering.
A record of something meaningful that happened in the business domain.
A persistence pattern where state is stored as a sequence of events rather than current values.
A collaborative workshop technique for exploring complex business domains through domain events.
Strategies for evolving event schemas over time without breaking existing consumers.
An architectural style where services communicate by publishing and reacting to events rather than calling each other directly.
A model where data across services becomes consistent over time rather than immediately after a change.
A retry strategy where the delay between attempts increases exponentially, preventing overload on failing services.
A function or method that encapsulates the creation of domain objects, ensuring they start in a valid state.
A high-performance RPC framework using Protocol Buffers for defining service contracts and generating strongly typed client and server code.
Ensuring that processing a message more than once produces the same result as processing it once.
Tests that verify your code works correctly with real infrastructure like databases and message brokers.
An event used within a single service or bounded context, not exposed to other teams or systems.
A design rule where domain objects enforce their own invariants so every instance is guaranteed to be correct.
The unit of data exchanged between publishers and subscribers through a message broker.
Infrastructure that sits between publishers and subscribers, routing messages between services.
Controlling the sequence in which messages are delivered and processed in an event-driven system.
Functions that wrap handlers with additional logic like logging, retries, or timeout management.
A team programming approach where the whole group works together on the same code, with one person driving.
A deployment model where the entire application runs as a single unit.
An approach where you start with a single deployable application and extract services later, only when there's a real reason to.
A context-mapping relationship where two bounded contexts can't function without each other.
A standard specification for defining HTTP APIs, enabling code generation for servers, clients, and documentation.
A coordination pattern where a central component controls the flow of a distributed process by sending commands and reacting to events.
Storing events in the same database transaction as data changes to guarantee delivery.
Splitting a topic into smaller segments so messages can be processed in parallel while preserving order within each segment.
A domain event that marks the boundary between two parts of the system, often where one team hands work over to another. The natural seam to split a flow into bounded contexts.
A deeper Event Storming pass that adds commands, actors, read models, policies, and aggregates around each event so the board can be translated into code.
A stateful orchestrator that coordinates long-running distributed processes by reacting to events and sending commands.
A language-neutral serialization format and interface definition language for defining service contracts and generating code.
A request to read the state of the system without changing it, handled by a dedicated handler in a CQRS architecture.
A data model optimized for queries, built from events in a CQRS architecture.
An abstraction that hides database access behind an interface, keeping business logic independent of storage.
Automatically re-attempting a failed operation, often with exponential backoff, to handle transient errors.
A pattern for managing distributed transactions by coordinating a sequence of local transactions with compensating actions.
A small, explicitly shared part of the domain model that two or more bounded contexts own together.
A migration strategy where a new system gradually replaces a legacy one by intercepting and redirecting requests.
The high-level half of DDD: figuring out where domain boundaries belong and how the parts of a system relate.
The code-level half of DDD: building blocks like aggregates, entities, value objects, repositories, and domain events.
A development practice where you write tests before the implementation, using failing tests to guide your design.
Limiting the rate at which messages or requests are processed to avoid overwhelming downstream services.
Tracking requests and messages as they flow through distributed services to understand system behavior.
A shared vocabulary between developers, stakeholders, and the codebase that keeps everyone aligned on what things mean.
Fast, isolated tests that verify your business logic without external dependencies like databases or message brokers.
A context-mapping relationship where one bounded context depends on another but not the other way around.
A domain object defined by its attributes rather than a unique identity, always kept in a valid state.
A tongue-in-cheek reminder that skipping planning to start coding faster usually costs far more time than the planning would have saved.
Loading...