Download to read offline
![Domain driven design
• Domain-driven design (DDD) is a major software design approach,[1] focusing on modeling
software to match a domain according to input from that domain's experts.[2]
• Under domain-driven design, the structure and language of software code (class names, class
methods, class variables) should match the business domain. For example, if software processes loan
applications, it might have classes like loan application, customer, and methods such as accept offer
and withdraw.
• Domain-driven design is predicated on the following goals:
• placing the project's primary focus on the core domain and domain logic;
• basing complex designs on a model of the domain;
• initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual
model that addresses particular domain problems.
https://en.wikipedia.org/wiki/Domain-driven_design](https://image.slidesharecdn.com/re-engineeringanenterprisewithddd-xpdaystalkbyrajuk-rajuk-230202204709-30966bf7/75/Re-engineering-Technology-to-break-barriers-with-Business-8-2048.jpg)
More Related Content
Similar to Re-engineering Technology to break barriers with Business
Re-engineering Technology to break barriers with Business
- 1. Re-engineering an Enterprise with Domain DrivenDesign RAJU K XEBIA
- 2. About Raj • EnterpriseAgile Coach • Professional ScrumTrainer • Xebia Agile Consulting and Transformation - North Americas Practice Lead
- 3. Time for apoll… If your current Enterprise is bit older (more than 15+ years) – What type of IT Systems do you see? A. Individual Silos supporting Line of Businesses B. Well organized, productized IT Systems focused on BusinessValue
- 4. Something familiar? • Enterprises– which are bit older – are designed and operated in this way: User experience/UI Applications APIs, Business Logic Platform & Ops Infrastructure Line of Business User experience/UI Applications APIs, Business Logic Platform & Ops Infrastructure Line of Business Shared services: Architecture, App Sec, SRE etc.
- 5. Key Challenges… • Bureaucracy •Power dynamics between Leaders • Lot of sunk costs in maintenance • Slow response times • Not easy to scale • Huge hidden costs of SW/HW licensing https://www.youtube.com/watch?v=whi2vzAc8VY
- 6. Better Future State •A re-engineered Enterprise – ready to take on the world BusinessValue Stream Infra & Platform
- 7. Conway’s law… • Anyorganization that designs a system, (defined broadly), will produce a design whose structure is a copy of the organization's communication structure. -- Melvin Conway, 1968
- 8. Domain driven design •Domain-driven design (DDD) is a major software design approach,[1] focusing on modeling software to match a domain according to input from that domain's experts.[2] • Under domain-driven design, the structure and language of software code (class names, class methods, class variables) should match the business domain. For example, if software processes loan applications, it might have classes like loan application, customer, and methods such as accept offer and withdraw. • Domain-driven design is predicated on the following goals: • placing the project's primary focus on the core domain and domain logic; • basing complex designs on a model of the domain; • initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems. https://en.wikipedia.org/wiki/Domain-driven_design
- 9. DDD – Boundedcontext • This is one of the most valuable constructs within DDD. • It provides the mechanism to break up large and complex systems into discrete pieces. • You will need to think of each as being its isolated from its neighbor, and loosely coupled via events & services Image source: BoundedContext (martinfowler.com)
- 10. DDD – Boundedcontext • One of the goals of Domain Driven Design, is to deliver software that directly reflects the common language of a given domain. • Let's use Making a car to illustrate the concepts of DDD. • Our illustration is going to cover the process of making a car.
- 11. Arrange these incorrect order • Can you arrange these steps in making a car in correct order? Procuring various components Assembling Transporting to a dealer Delivering to a Dealer Painting
- 12. High level flow •Lets start with the high-level flow Procuring various components Assembling Transporting to a dealer Delivering to a Buyer Painting
- 13. Buyer Dealer Transporter High level flow •The Domains of making a car – from a car perspective Manufacturing Plant
- 14. Buyer Dealer Transporter Vocabulary… • Notice howeach Domain has its own unique language and vocabulary Manufacturing Plant Product Load Business Need or Status Symbol
- 15. Buyer Dealer Transporter Vocabulary… • Each domainhas its own understanding of the “car” • These can lead to Silos/Monoliths… Manufacturing Plant • Bill of Material • Assembly Line • Configuration • Final Destination • Route • Weather conditions • Other vehicles in load • Down payment • Payment terms • Delivery Dates • Exchange/ Trade-in • Mileage • Maintenance costs • Accessories • Installments if any
- 16. Domain and Context •To bring all these into a common understanding, we have to set the context boundaries • Each domain will expose its services so other domains can consume the same – creating a BusinessValue Stream perspective Buyer Dealer Transporter Manufacturing Plant Product is the “car” Load is the “car” Business is the “car” Need or Status Symbol is the “car” • GetBoM() • RoadTest() • NSRTest()… • GetLoad() • PlanLoad() • Track()… • SalesOrder() • Customer_Account _Creation() • Process_Order()… • Do_PaperWork() • Do_PDI() • Take_Delivery()…
- 17. DDD through EventStorming Event Something that has happened <noun> <verb>, e.g. order submitted Command An action started by a policy in response to an Event Capability Component A component that is part of a business capability within the Domain. This becomes a micro-service. System An External system or service which is outside the Domain Data The information that represents an Event Policy The reaction to an Event: When <event> then <command> Sub Process A sub process which is reused or defined in a separate event storm Question or Assumption A question or assumption that requires follow up
- 18. An example Event Something thathas happened <noun> <verb>, e.g. order submitted A New order at Manufacturing Plant Command An action started by a policy in response to an Event Raw materials are procured Capability Component A component that is part of a business capability within the Domain. This becomes a micro-service. GenerateVIN Label, Sticker System An External system or service which is outside the Domain Notify Government Agencies Notify the Dealer and/or Buyer Data The information that represents an Event Car status is “in Transit” Policy The reaction to an Event: When <event> then <command> Wrap the car to protect from damages Sub Process A sub process which is reused or defined in a separate event storm Get Route approvals/permits etc. Question or Assumption A question or assumption that requires follow up Vehicles are secured during Transport
- 19. Our flow… Process payment service Preferred Delivery date Iwant to buy a car Offer pre-delivery inspection Buyer Name, address, contact Send Vehicle and Buyer details Car is shipped Book a car Car received by Dealer Car booked Support preferred delivery date of Buyer Process payment service Licensing details This emerging pattern is defining the Bounded Context for the Capability Component This is our first Deliverable Artifact: It is a map of the Domain's processes. MV/RTO Database Data Policy Command Capability Component (Aggregate) Event External system Legend:
- 20. After the storm… •A Capability Component now has a Bounded Context. The Bounded Context is revealed when you remove the Events and Policies Leaving behind the Components, Data, and Commands Update Dealer Order Update Service Get Payment Assemble the car Procure Raw material Shipping Payment Order Car Details, Configuration • The Commands will become API resources or Message subscriptions • The Data entities will become the Data Model • The Capability Component is the Logic (Policies) and State (Data Model) necessary to turn Commands into Events This is our Second Deliverable Artifact: Identify the Components and their Bounded Contexts
- 21. … the endgame ! • With the Bounded Context defined, a Capability Component becomes a Micro-Service that we can code and deploy! Update Dealer Order Update Service Get Payment Assemble the car Procure Raw material Shipping Payment Order Car Details, Configuration Now the real work begins. The Event Storm got us to the Bounded Context. So, now we can define our API or Message Contracts, the underlying Logic, and derive the Data Model.
- 22. Capability Component (Microservices) Business Capability Product/Service Domain FinalExample Car Manufacturer Make the car Orders Order Management Payment processing Shipping Load Planner Route Planner Dealers Sales & Delivery Inventory Management Service Service Orders Spares and Accessories Training Domain - L1 Product - L2 Business capability - L3 Capability Component - L4 Business capability – L3 Capability Components – L4 Product - L2 Business capability - L3 Capability Component - L4 Business capability – L3 Capability Components – L4 Products & ServicesTaxonomy Services (e.g. Microservice)
- 23. Execution Plan Domain Products /Services Microservices aka Capability components Domain 1 Capability 1 Capability 2 Capability 3 Domain 2 Capability 4 Capability 5 Capability 6 etc…. MVP Increment Capability 1 Capability 2 Capability 3 Next Increment Capability 4 Capability 5 Capability 6 etc…. Next Increment Capability 4 Capability 5 Capability 6 DDD 1a – Establish business process & Identify Domains and boundaries 1b – Event storm on domains and define capabilities 1c – Breakdown domain / capabilities into candidate Microservices Decomp 2a – Analyze current applications and decompose them to capabilities 2b – Map capabilities to DDD identifies (Step 1) services Build 3b – Initiate development on MVP (First Increment) 3c – Create execution roadmap for application based on capabilities 2c – Identify MVP scope (Initial set of capabilities) 3d – Next Increment planning 3a – Kick-off with dependent domain owners Iterate
- 24. Agility at thecore of DDD • XP Practices – Collective Code ownership, Refactoring etc. • Short 2-week Sprints within a quarter increment cycle – frequent inspect and adapt opportunities • MVP Concepts helping Business to re-engineer and reap Agility benefits • BusinessValue Streams providing a unified view of the Enterprise – ease in planning, budgeting and execution
- 25.
- 26.