Domain-Driven Design

Makes domain knowledge visible as a chronological wall of events, from domain events through commands to bounded contexts.

Core question: Which business events, triggers, and boundaries shape the flow, and where do friction, risk, or learning needs arise?

• 2-8 h
• 5-12

Clarifies the language, model boundaries, and responsibilities of a business context before integration and team boundaries are fixed.

Core question: Where should this domain boundary sit, and how will contexts collaborate?

• 1-3 h
• 3-8

Translates domain knowledge into a narrated situation where terms, relationships, and rules are checked together.

Core question: How do actors work toward a business outcome, including exceptions?

• 1-2 h
• 2-8

Links events, commands, and views into a flow picture that brings UI, behavior, and implementation together.

Core question: Which events, commands, and views explain the system behavior over time?

• 2-6 h
• 2-8

Shows relationships between business contexts and makes integration patterns, dependencies, and friction points visible.

Core question: Which models apply where, and how do contexts influence one another when collaborating?

• 1-3 h
• 2-8

Makes domain boundaries, ownership, and relationships visible so modeling questions and responsibilities get cleanly resolved.

Core question: Where do particular models apply and how must their owning teams collaborate?

• 1-3 h
• 3-10