apidays London 2023 - Why and how to apply DDD to APIs, Radhouane Jrad, QBE Europe

apidays London 2023 - APIs for Smarter Platforms and Business Processes
September 13 & 14, 2023

Why and how to apply DDD to APIs
Radhouane Jrad, Lead Integration Architect at QBE Europe

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Domain Driven Design 2023 © Mother Earth Radhouane Jrad
2. The Plan • DDD in General (History, etc.) • Designing in DDD • Implementing DDD: Use-Case • Implementing DDD Principles • DDD & Horizontal Scalability • Principles Guiding API Governance 02/23
3. Disclaimer DDD is a rich, complex, sometimes antagonistic topic. This presentation is an implementation of DDD and some aspects may differ from other implementations. The views in this presentation fairly (but not fully) adhere to standard DDD concepts. 03/23
4. Mantra As a developer, it is your understanding, rather than your knowledge, that becomes software! Alberto Brandolini 04/23
5. Origins: 2003 05/23
6. How Did We Get to DDD? Business Model Business Domain Domain Driven Design • Describes core aspects of company’s values (economic, social, environmental, etc.) & how it ‘lives’ them • Reflects rationale of a company’s purposes, processes, markets, products & services, strategies, infrastructure, operational processes, policies, etc. Business Strategy • Defines goals of the company • Competitive matters: How to fight & compete? What are our strengths & weaknesses? Where are market opportunities? Lateral concerns (social, societal, environmental, etc.) • Different to Operational Strategy (efficiency, cost mgmt., etc.) Corporate Strategy • Existential matters: • What business should we be in? • What business should we NOT be in? • Essentially, 2 types of models: • Linear (aka Pipes): upstream production & downstream consumption, e.g. ink > pen + lid > wholesale • Networked (aka Platforms): multi-directional exchange (e.g. Digital Transformation) • We start getting technical: • A “simple view” of a “complex Reality (UML) • Class-based representation of objects being implemented • Generated through Business Modelling & designed by Business Analysts. • Categorises the set of business systems that represent autonomous units of the business modeled during Business Analysis. Strategy Operations Infrastructure • Aim is to structure the code and its language to reflect the Business Domain • e.g. Class ClaimApplication; + Class Customer + method approveClaim + method rejectClaim 06/23
7. The Concept of Domain Driven Design Business Domain Domain Driven Design • We start getting technical: • A “simple view” of a “complex Reality (UML) • Class-based representation of objects being implemented • Generated through Business Modelling & designed by Business Analysts. • Categorises the set of business systems that represent autonomous units of the business modeled during Business Analysis. • Aim is to structure the code and its language to reflect the Business Domain • e.g. Class ClaimApplication; + Class Customer + method approveClaim + method rejectClaim 06/23
8. When to Use DDD? 07/23
9. Meaningfulness of DDD 08/23
10. DDD Strategic Tools 09/23 Sleeping Compartment Engine Room Logistics Kitchen Captain’s Corner Viewing Deck Gathering Area
11. DDD Strategic Tools 10/23 Dining Room Kitchen Master Bedroom Garage Guests Room Living Room Kid’s Room Master Storage Storage Front Lawn Shower/WC
12. Designing in DDD 11/23
13. Insurance Example Customer = Active policies, historical policies, MTA Domain: Policy Customer = Open claims, historical claims, NCD status Domain: Claim Customer = Name, physical address, mobile no. Domain: Party DB API DB API DB API 12/23
14. Case Study: Integration for Insurance 13/23
15. Policy Domains Cross-Contamination 14/23 Claims DGL API AL API ACL API DGL API AL API ACL API Consumer A Sys. Of. Rec X Claims
16. Policy Domain Gateway Layer APIs 15/23 Claims DGL API AL API ACL API DGL API AL API ACL API Consumer A Sys. Of. Rec • DGL API act as gateway to the domain • Every domain’s Abstract Layer is constructed, developed, and maintained ignoring other domains • Every domain’s ACL is constructed, developed, and maintained ignoring other domains • Security, Infrastructure, Testing, and Asset Reusability requirements are easy to address • Usually one DGL API per Domain.
17. Domain Gateway Layer APIs 16/23
18. Claims Policy The Case of a Common System of Records 17/23 DGL API AL API ACL API DGL API ACL API Consumer A Sys. Of. Rec Consumer B X
19. Claims Policy Anti-Corruption Layer 17/23 DGL API AL API ACL API DGL API ACL API Consumer A Sys. Of. Rec Consumer B Claim Processes Need Policy no? Policy Processes
20. DDD & Horizontal Scalability 18/23
21. Instance A (1 CPU Unit) DDD & Horizontal Scalability 19/23 Step 1 Step 2 Step 3 Step 4 Step 5 Instance B (1 CPU Unit) Step 1 Step 2 Step 3 Step 4 Step 5 Queues Queues
22. Some Notes: 20/23
23. Principles Guiding API Governance 21/23 Structural Principles Feedback-Based Design (DSR) SOLiD: •Single Responsibility Principle (SRP) •Open/Close Principle (OCP) •Liskov, Interface Segregation Principle (ISP) •Dependency Inversion Principles Reusability Primacy of Principles Domain Driven Design Separation of Concerns Three-layered Architecture API-Led Architecture YAGNI Minimise Coupling KISS Git-based Version Control O-Auth based Security C-back with JWT Asset exposure (Marketplace) IPaaS (Managed Services) API Catalogue Logging Smart Endpoints, Dumb Pipelines Asynchronous vs. Synchronous Queues vs. EDA vs. Pub/Sub Driving Principles Technological Baseline Security By Design Horizontal vs. Vertical Scalability Singular Technology Integration Inventory Load Balancers REST vs. SOAP Component Based Statelessness
24. API Building Blocks 22/23 Domain Driven Design API-Led Design Pattern Horizontal- First Scalability REST-first , JSON-first Integration iPaaS Security By Design Product- based Reusability; Evolvability; Extensibility; Security; Cost-Effectiveness; Auditability; Clarity; Simplicity/Simplification…
25. Thanks 23/23 LinkedIn: Radhouane Jrad Questions? 2016 2013 2003 Some Good Reads: