Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Domain Driven Design

13 visualizaciones

Publicado el

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.

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Domain Driven Design

  1. 1. Domain Driven Design (DDD) Muhammad Ali
  2. 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. 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. 4. Goal  A domain specific project that needs to leverage multiple realms of expertise specifically  Design and Developer expertise  Domain specific expertise
  5. 5. Glass Law “Requirement deficiencies are the prime source for project failures”
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Identifying Entities & Value Objects  Ticket  Receptionist  Store Staff  Customer  Consultant  Consultant Evaluation  Work Log Entities Value Objects
  22. 22. Identifying Actions  AddTicket  Routing  Service  Consultant Evaluation  TrackWork
  23. 23. Attributes  What about other attributes? Like  Location awareness  Skills  Availability
  24. 24. Results
  25. 25. Results
  26. 26. “All models are wrong; some models are useful” George E. P. Box
  27. 27. Questions?

×