This workshop focuses on domain driven design and how to achieve it effectively. It also focus on bridging gaps while gathering requirements from business stakeholders using event storming workshops.

1. Domain Driven
Design (DDD)
Muhammad Ali

2. Conway's law
“Any organization that designs a system (defined more broadly here than just
information systems) will inevitably produce a design whose structure is a copy of the
organization's communication structure.”

3. What is domain-driven design
 Domain-Driven Design is an approach to the development of complex software in which we:
 Focus on core domain
 Explore models in a creative collaboration of domain practitioners and software practitioners
 Speak a ubiquitous language with in an explicitly bounded context

4. Goal
 A domain specific project that needs to leverage multiple realms of expertise specifically
 Design and Developer expertise
 Domain specific expertise

5. Glass Law
“Requirement deficiencies are the prime source for project failures”

6. Complications
 Most of the times developers speak in terms of Objects, composition, aggregation, inheritance, polymorphism,
pure functions etc.
 They talk more about technical solution rather than the problem itself.
 At times they don’t understand the underlying complexity and overcommit.
 Domain expert don’t know any of these, he has his own jargons regarding the domain.
 For example marketing people talking about leads, ads, campaigns, budgeting units etc.
 Similarly domain expert in airline talking about crew planning, SAFE, roster planning, FBO, PFA etc.

7. Boehm’s First Law
“Errors are most frequent during the requirements and design activities and are the
more expensive the later they are removed”

8. Solution
 Strengthen the communication process and establish a methodology for making those communication more
robust
 This is primarily accomplished by developing a UBIQUITOUS LANGUAGE and single model
 Make sure your developers speak this ubiquitous language.
 Persistent use of the UBIQUITOUS LANGUAGE will force the model's weaknesses into the open
 Building a language like this has a clear outcome:
 Language and model are strongly interconnected with each other
 Any changes to the language will be recognized as changes in the domain model

9. Domain Model
 A system of abstraction that describes selected aspects of a domain and can be used to solve problems related
to that domain.
 A domain model in not a particular(UML) diagram(unlike Model-Driven Design), it is the idea that diagram is
intended to convey.
 Model can be an expression in natural language, code or a diagram.
 Model is not a design artifact
 Model are the backbone of domain-driven design
 The model is distilled knowledge
 It is not just the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of
that knowledge

10. Implementation
 Once Domain Model is defined, you can identify different components based on their properties
 You can divide your solution into different layers(so called layered architecture, MVP, MVC,VIPER, MVVM etc)
 For example following we can break down our solution into following layers
 Presentation Layer (UI or ReST/SOAP/XMLRPC)
 Application Layer (Define the jobs that software is supposed to do and direct the expressive domain objects to work
out problems.)
 Domain Layer(Contains Business Logic)
 Infrastructure Layer(Provides generic technical capabilities, like message sending, persistence etc.)
 There can be multiple layers with different names however Domain-Driven design only requires domain layer.

11. Entities
 An object defined primarily by its identity is called an Entity.
 Each entity must have an operational way of establishing its identity with another object
 An identifying attribute must be guaranteed to be unique within the system however that system is defined,
even if distributed, even when objects are archived

12. Value Objects
 An object that represents a descriptive aspect of the domain with no conceptual identity is called aValue
Object.
 The attributes that make up aValue Object should form a conceptual whole
 Immutability should also be considered when designingValue Objects
 As long as aValue Object is immutable, change management is simple

13. Services
 There are important domain operations that can't find a natural home in an Entity orValue Object
 A Service is an operation offered as an interface that stands alone in the model, without encapsulating state, as
Entities andValue Objects do.
 Services are a common pattern in technical frameworks, but they can also apply in the domain layer.
 A good service has following characteristics
 The interface is defined in terms of other elements of the domain model
 The operation relates to a domain concept that is not a natural part of an Entity orValue Object.

14. Aggregates
 An aggregate is a cluster of domain objects that can be treated as a single unit
 Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates.
Transactions should not cross aggregate boundaries.
 An aggregate will have one of its component objects be the aggregate root.
 Any references from outside the aggregate should only go to the aggregate root.
 The root can thus ensure the integrity of the aggregate as a whole.
 A delete operation must remove everything within the aggregate boundary at once
 When a change to any object within the aggregate boundary is committed, all invariants of the whole aggregate
must be satisfied.When a change to any object within the aggregate boundary is committed, all invariants of
the whole aggregate must be satisfied.

15. Bounded Context
 Bounded Context is a central pattern in Domain-Driven Design
 DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their
interrelationships
 Total unification of the domain model for a large system will not be feasible or cost-effective
 So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model

16. Context Map
 An individual Bounded Context still does not provide a global view.The context of other models may still be
vague and in flux
 Code reuse between Bounded Context is a hazard to be avoided.
 A Context Map is the overlap between project management and software design.
 A Context Map is a document which outlines the different Bounded Contexts and the relationships between
them.
 The level of detail may vary. What it is important is that everyone working on the project shares and
understands it.

17. Event Storming
 The smartest approach to collaboration beyond silo boundaries
 Event Storming is a flexible workshop format for collaborative exploration of complex business domains.
 Event storming is a rapid group modeling approach to domain-driven design.
 Originally created by Alberto Brandolini in 2012 as a quick alternative to precise UML diagramming
 Extremely lightweight, and doesn’t require any gadget
 The business process is "stormed out" as a series of domain events
 Result is a set of sticky notes consists of command, event, aggregate, view, business process, issues and
external system

18. Sysop Squad
 An electronics giant needs a new trouble-ticket system for their customer-facing IT consultants (the Sysop
Squad) in their stores nationwide
 Requirements: trouble tickets can be entered by either call-center receptionists, store staff or customers
online; tickets route to the appropriate consultant based on location, availability and skill; customers enter
consultant evaluation after service; consultant tracks work performed in customer record(s) for future reference
 Users: thousands of customers, hundreds of consultants, hundreds of store staff

19. Sysop Squad
 An electronics giant needs a new trouble-ticket system for their customer-facing IT consultants (the Sysop
Squad) in their stores nationwide
 Requirements:TroubleTickets can be entered by either call-center Receptionists, StoreStaff or Customers online;
tickets route to the appropriate Consultant based on location, availability and skill; customers enter consultant
evaluation after service; consultant tracks work performed in customer record(s) for future reference
 Users: thousands of customers, hundreds of consultants, hundreds of store staff

20. Sysop Squad
 An electronics giant needs a new trouble-ticket system for their customer-facing IT consultants (the Sysop
Squad) in their stores nationwide
 Requirements:TroubleTickets can be entered by either call-center receptionists, store staff or customers
online; tickets route to the appropriate consultant based on location, availability and skill; customers enter
consultant evaluation after service; consultant tracks work performed in customer record(s) for future
reference
 Users: thousands of customers, hundreds of consultants, hundreds of store staff

21. Identifying Entities & Value Objects
 Ticket
 Receptionist
 Store Staff
 Customer
 Consultant
 Consultant Evaluation
 Work Log
Entities Value Objects

22. Identifying Actions
 AddTicket
 Routing
 Service
 Consultant Evaluation
 TrackWork

23. Attributes
 What about other attributes? Like
 Location awareness
 Skills
 Availability

24. Results

25. Results

26. “All models are wrong; some models are useful”
George E. P. Box

27. Questions?