Designing Clear Context Boundaries and Integration Strategies(Domain Driven Design)

This reference lists the core entities and integration patterns used to represent business capabilities and their interactions. Each entry focuses on the technical role, lifecycle implications, and integration responsibilities so engineers can map requirements to implementation choices and integration strategies.

Modeling based on author's perspective

Entity	Description
Business Process	Ordered workflow of activities that produce business value and define functional requirements.
Problem	Concrete business constraint or requirement that drives solution design and acceptance criteria.
Domain	Area of expertise and rules the system must represent and enforce.
Sub-Domain	Scoped portion of the domain with its own responsibilities and business rules.
Core Domain	Strategic sub-domain containing the primary differentiating logic and competitive advantage.
Supporting Domain	Sub-domain that enables core capabilities but is not the main source of differentiation.
Generic Domain	Reusable, commodity functionality that can be implemented with off-the-shelf solutions.
Bounded Context	Explicit boundary where a single model and vocabulary are authoritative and consistent.
Domain Model	Structured set of concepts, invariants, and relationships used to implement domain logic.
Ubiquitous Language	Shared, precise vocabulary used by developers and domain experts to avoid ambiguity.
Parts	Collection of model elements (messages, entities, value objects, services) composing the design.
Message	Typed payload used for commands, events, or integration between components or contexts.
Entity (domain entity)	Mutable object with a stable identity and lifecycle, encapsulating state and behavior.
Object	General conceptual element representing a thing with attributes and operations.
Value Object	Immutable type defined by its attributes; equality by value, no identity required.
Service	Stateless operation encapsulating domain logic that does not naturally belong to an entity.
Inter-Context Relationship	Pattern describing integration, ownership, and data flow between separate bounded areas.
Partnership	Collaborative integration where contexts coordinate and share responsibilities.
Customer/Supplier	Asymmetric contract: one context requests functionality and another provides it.
Open-Host Service	Public service interface offered by a provider context for consumption by others.
Anti-Corruption Layer	Translation/adaptation layer that isolates a context from incompatible external models.
Conformist	Integration approach where a context accepts and uses another context's model without translation.
Shared Kernel	Small, jointly maintained subset of the model shared to ensure consistency across contexts.
Separate Ways	Independent evolution: contexts remain decoupled and do not integrate operationally.

Treat these definitions as implementation primitives: use them to standardize vocabulary, drive interface contracts, and reduce coupling between teams and services.