๐ก Domain-Driven Design (DDD) EventStorming โ Executive Summary
Technical architectural analysis, practical configuration manifests, and deployment instructions for Domain-Driven Design (DDD) EventStorming.
MSA-based design performance process
- Deriving microservices
- Domain identification and definition of relationships between data
- Microservice identification
- Definition of internal architecture
- Establishment of MSA-based design principles reflecting organ system characteristics
- Status analysis/microservice design based on business requirements
- External architecture definition
- Selection of reference model for optimal technology application
- Optimized design for each technology element (logic/physics)
- Capacity and cost design
- Infrastructure capacity (container perspective) design for service construction
- MSA-based
How to derive microservices
- There are two ways to derive microservices:
decomposition by business functionanddomain-driven design - Breakdown by business function
- 3Depth classification and detailed function description based on function tree
- Domain Driven Design (DDD)
- High cohesion and low coupling by decomposing services based on the lower subdomains that make up the business domain
- Domain: Business goal or smaller functional goal unit (subdomain)
Domain Driven Design
- Design meeting between developers and designers
- Complete understanding of domain and domain model before code
- Closely linking code and model
- Activities to understand and explore large and complex domains
Terminology and core content
- Bounded context
- Identifies boundaries between domains
- Ubiquitous language
- Language commonly used by project personnel
- Core subdomain
- Business Specialization
- Supported subdomains
- Optional area
- General subdomain
- Business Specialization
- Strategic Design
- Role that identifies microservices
- As the design continues to grow, classification based on importance is necessary
- Separate a large domain into subdomains and divide them into core, support, and general subdomains
- Bounded context is 1:1 or 1:N
- Find relationships between contexts and create a context map
- Design process
- Defining a ubiquitous language for modeling the inside of a bounded context
- Analyze the business and identify key concepts by analyzing the common language above
- Identify Bounded Context by analyzing identification concepts
- Create a context map by defining the mapping relationship of bounded context
- Analyze the effects of division and divide or integrate
- Microservice definition
- Tactical Design
- Event Storming
- How to do it
1. Find domain events
2. Command definition and command user identification
3. Classify domains into subdomains
- How to do it
- Participants: Stakeholders
- Domain Expert
- Analyst
- Product Owner
- Developer
- What you need:
- Post-it
- Large roll paper
- Location:
- Large wall space without chairs
- Basic steps to follow:
- Domain Event (orange)
โ Attached in chronological order
โ Write in past tense sentences (eumseum font)
โ Predefine ubiquitous language to avoid using redundant or ambiguous words - Process / External System (pink)
โ When a domain event calls one or more steps of a execution process
โ When linkage with an external system is required - Hot spot (purple)
โ Question / Assumption / Warning / Complete if opinion collection is required- About domain events or processes / external systems
- Even in cases of ambiguous required/optional values, etc., Throw
- Command (blue)
โ Can be API or Function unit
โ In case of batch domain event, command may not be present
โ Caused by a domain event, or may be the cause of a domain event - Actor (light yellow, small post-it note)
โ Attach below command
โ user executing command (specified in ubiquitous language) - The activity of dividing a domain into multiple subdomains
- Entity/Egret (dark yellow, large post-it note)
- Overlapping between command โ domain event
- Record of object characteristics with a specific ID, or result achieved by command
- Identification of bounded context
- After identification, indicate whether communication between subdomains is synchronous or asynchronous
- Microservice identification
- Even in the same bounded context where functional similarities exist, functional units can be divided into small parts by dividing the parts where functional development mainly takes place and those where it does not.
- Domain Event (orange)
- Advanced procedures:
- Read Model (green)
- User performs command data that serves as the basis for decision
- User Interface (white)
- Sketch-type screen layout
- Policy (light blue)
- Event Decision based on conditions (IF)
Insight
- Complex code is created due to non-procedural additional functions that occur during general software design




Leave a Reply