Glossary
A
Agile. Agile is the ability to create and respond to change. Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. Many different frameworks exist that espouse to be “agile” including frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).
Aggregate root. An aggregate defines a boundary that separates the entities inside it from the rest of the application. The entity representing the central business concept in the aggregate will act as the aggregate root. Good domain driven design specifies that a bounded context should have only one aggregate root.
Artifact. Any asset or piece of information that contributes to a project’s outcome, including, for example, designs, drawings, templates, architectural stereotypes, models, documentation, source code, and other information that is required to deliver the end product.
B
Boss Logic. The organization behind Customer Obsessed Engineering, and a company I originally co-founded back in the mid-1990s.
Bounded context. A bounded context is what knits together a collection of related entities, data, behaviors and their ubiquitous language into a related model. It creates a boundary inside of which we want consistency: Everything inside the boundary needs to be closely related, and share the same ubiquitous language.
Business capabilities. Business capabilities define a concrete list of business functions or product features. They have a degree of similarity to “business domains,” such as fraud prevention, order processing or warehousing. Throughout the playbook, business capabilities are further defined by enumerating use cases the define specific functionality within the capability. (See: 1.4 Business capabilities and functions).
Business objectives. Business objectives define high-level initiatives that establish your long-term strategic goals. An initiative encompasses a whole business outcome or capability, such as “deliver a modern, accessible user experience that surpasses our competitors.” (See: 2.1 Business strategy).
C
Ceremony (sprint ceremonies). Activities proscribes by the sprint, project, or methodology, specifically for the purpose of maintaining the health of the project and communication among the stakeholders.
Context. The setting in which a word or a statement appears that determines its meaning.
Context map. A visual map of your bounded contexts that clearly indicates how each context depends upon and communicates with other contexts. Relationships between contexts (“interfaces”) are shown, along with additional detail (such as where anticorruption layers are needed, and whether an interface is upstream or downstream).
Control process. Any activity or process that checks for errors or outlying conditions and defines corrective action to compensate for them. For example, a control process around bank account withdrawals is to verify that sufficient funds are present before making the withdrawal.
Customer Obsessed Delivery Playbook (or Delivery Playbook). A technique for making sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments. Paid subscribers can access the Customer Obsessed Delivery Playbook online.
Customer personas. A persona fills in a picture of a specific customer, the customer’s needs, and obstacles or drivers that might motivate them. Personas are used throughout user journeys to capture how different users interact with systems.
D
Definition of Done (DoD). A “Definition of Done” is a shared understanding among team members of what it means for work to be considered complete. Any criteria that are deemed important are included, such as, “the work has been fully reviewed by another team member.”
Definition of Ready (DoR). A “Definition of Ready” outlines the criteria required in order for the team to begin work on an item. Having this criteria in place protects the effort of the team, for example, by preventing the team from working on something that still has external dependencies.
Domain. A domain is a collection of related concepts, relationships, and workflows.
Domain Driven Design (DDD). A software design approach focusing on modeling software to match a business domain according to input from domain experts. It involves concepts such as ubiquitous language, strategic design, tactical design, entities, value objects, aggregates, and more. (See: The 30-minute guide to Domain Driven Design).
Domain logic. The unique value of your application — the purpose and rules that implement your processes. It’s how your business processes are codified, defining how data is handled.
Domain model. A system that describes the selected aspects of a domain and that is often used to solve problems related to that particular domain.
E
Entity. Entities are the unique and identifiable representation of things in our business domain or bounded context: A combination of behavior and data. A customer, an account, and a merchant are all good examples of entities.
Event storming. A workshop-based method to quickly find out what is happening in the domain of a software program. Compared to other methods it is extremely lightweight and intentionally tries to avoid introducing technology limitations by focusing on business events. The result is often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Strategic event map).
I
Infrastructure as Code (IaC). Infrastructure as Code (IaC) is the practice of building and integrating provisioning, configuration and deployment into tools and workflows by identifying places where control processes, tests, and infrastructure provisioning may be implemented using automation.
K
Kanban (“kanban”). A scheduling system for lean manufacturing (also called just-in-time manufacturing, abbreviated JIT). Taiichi Ohno, an industrial engineer at Toyota, developed kanban to improve manufacturing efficiency. The system takes its name from the cards that track production within a factory. In kanban, problem areas are highlighted by measuring lead time and cycle time of processes. One of the main benefits of kanban is establishing an upper limit to work in process.
M
Methodology. A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods (American Heritage dictionary). Specifically, in this context, a software delivery methodology such as Scrum or Kanban that focus on the mechanics of team organization, collaboration, and ceremony around software delivery.
N
Non-value add (non-value add effort). Any activity or effort that does not add to or create value. In the context of a waste walk activity, indicates those activities that do not contribute directly to the current sprint, specifically toward the goals of the sprint (or project outcomes).
North Star (North Star vision). An overarching representation of a system’s intended realization, typically including conceptual high-level models, some example level of concrete architectural implementation, and delivery standards. The intended outcome of a North Star vision is to establish clear boundaries and guardrails for technical implementation. It usually demonstrates how architectural concepts are realized into actual implementation. It also provides design pattern standards, for example, by defining that a given architecture is service based and that services communicate using an event stream architecture.
Q
Quality gates. A milestone in a project that requires predefined criteria be met before the project can proceed to the next phase. Typically, these are verifications you can implement in the software development pipeline to prevent artifacts from moving forward if they don’t meet specified quality criteria.
P
Playbook. A set of rules, suggestions, or methods that are considered to be suitable for a particular activity, industry, or job.
Product mindset. An approach to product development that creates product oriented teams (as opposed to project oriented teams). Product oriented teams are cross disciplinary and fully enabled to deliver a product, from ideation to operations. (See: Moving away from the Monolith: faster, better with a product mindset).
Product vision. A statement that establishes an overarching long term direction for your product and serves as a guidepost for all involved stakeholders. Vision statements define why you are creating the product and what the company’s intended outcome is. (See: 1.3 Product vision).
R
RACI. A responsibility assignment matrix or linear responsibility chart. It provides a model describing the participation by various roles in completing tasks or deliverables for a project. RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed.
S
Scrum. An agile framework that provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs. The Scrum framework is made up of a Scrum team consisting of a Product Owner, a Scrum Master and developers, each of which have specific accountabilities. Scrum defines the events that the team participates in, and the artifacts produced by those events.
Security as Code (SaC). Security as Code (SaC) is the practice of building and integrating security into tools and workflows by identifying places where security checks, tests, and gates may be included and implemented as configuration or software, in an automated fashion.
Service catalog. Much like a restaurant menu, a service catalog provides a menu of available technology choices — services, hardware, software, products and support options — available to use in delivery. It is the “toolbox” of the development team. Some commercial service catalogs may also offer a way to propose, reviewing and adopt new technologies.
Stakeholder. Individuals or organizational units that have an interest in and may be affected by the outcomes of the project.
Steel thread. A development technique that achieves an architecturally complete feature delivery to production very rapidly by aggressively controlling risk. It deals with risk and complexity up-front, while also focusing on a proof of architecture during the first few working sprints. (See Plagued with problems getting to delivery? Solve them with a “steel thread.")
Stereotype (architecture stereotype). A standardized mental picture that is held in common by members of the team and that represents a simplified, opinionated approach to realizing the specific design, providing overarching guardrails and definitions regarding the key elements and standards of the architecture. Often expressed as design prints that model the key components of a system.
Strategic event map. A visual representation of the business processes within a specific domain. Developed during event storming, the “map” is usually a series of commands and events that take place over time. Often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Event storming).
SWOT. A strategic planning and strategic management technique used to help a in identifying Strengths, Weaknesses, Opportunities, and Threats related to business competition or project planning.
Systems Development Life Cycle (SDLC). Also referred to as an application development life cycle, an SDLC is a process for planning, creating, testing, and deploying an information system. (See: SDLC, also related to software development process).
T
Tactical event map. A visual representation of the detailed activities that support a business process (hence “tactical,” versus “strategic.”) Developed by extending a strategic event map, adding underlying operations (such as external calls, persistence operations, read models and state change). Often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Strategic event map).
Template. A document or file having a preset format, used as a starting point for a particular application, component, or document, so that the format does not have to be recreated each time it is used.
U
Ubiquitous language. Ubiquitous Language is a Domain Driven Design term describing a common, rigorous language between developers and users. It is based on the domain model and needs to be rigorous, since software doesn't cope well with ambiguity. Using ubiquitous language in conversations with domain experts tests the model, and creates common understanding between stakeholders. (See: Do you understand your customer?).
Use case. Use cases are descriptions of how a customer (or user) interacts with a system. (See: What are use cases?).
User journey. User journeys tie together different use cases or “user stories” that a customer has with a system, following a user through different stages. Together, a collection of use cases make up the user journey. (See: What about “user journeys?”).
V
Value add (value add effort). Any activity or effort that creates value. In the context of a waste walk activity, indicates those activities that are creating value within the current sprint, specifically attributed toward the goals of the sprint (or project outcomes).
Value mapping (value-stream mapping). Value-stream mapping, also known as material- and information-flow mapping, is a lean management method for analyzing the current state and designing a future state for the series of events that take a product or service from the beginning of the specific process until it reaches the customer.
Value object. Small, immutable objects that represent a concept in our domain. They don’t implement identity and typically won’t implement business logic. Two value objects are considered equal if their properties are equal.
Value Stream Engineering. A set of practices that improve the way teams deliver high-quality customer experiences. It focuses on how quickly customer requested features or updates are delivered and whether the customer realizes the intended value from those features.
W
Waste walk. A tool or technique to identify and eliminate waste, ultimately optimizing operational efficiency. By conducting waste walks, businesses can uncover hidden opportunities for improvement, streamline processes, and enhance overall productivity.
Waterfall. A widely used project management method with a linear approach, having its roots in industrial design process. In a waterfall methodology, each stage of workflow is completed before moving on to the next step. While there are different types of project management methodologies, waterfall is well suited for projects where the objectives are clearly outlined from the beginning.