Downloaded 25 times
Uploaded byCan Pekdemir
Domain Driven Design & Hexagonal Architecture
This document discusses Domain Driven Design and Hexagonal Architecture for handling complex business logic. It covers key concepts like ubiquitous language, bounded contexts, aggregates, domain events, and anti-corruption layers. It also discusses how Amazon used these principles to scale up to thousands of microservices handling over 6000 employees in many countries. The Hexagonal Architecture approach helps abstract business code from frameworks and make architectural changes easier through separating domains from infrastructure.
In this document
Powered by AI
Overview of Domain Driven Design and Hexagonal Architecture by Can Pekdemir, including personal background and expertise in various business domains.
Definition of Domain Driven Design from Eric Evans including growing complexity and time to market, discussing misconceptions in software as a cost center.
Introduction to Domain Driven Design as a solution for complex business problems, focus on collaboration, Ubiquitous Language, and Managing Bounded Contexts.
Strategic design using Bounded Context with insights on scaling such as Amazon's practices and Uber's statistics with over 1000 microservices.
Context mapping and relationships of Bounded Contexts, Anti Corruption Layers, and integration strategies using RESTful API and messaging.
Explanation of Aggregates in domain design including rules for aggregate design and managing business logic consistency.
Introduction to Domain Events for tracking occurrences and organizing code to avoid unnecessary complexity.
Definition of Hexagonal Architecture and its benefits, emphasizing separation of business logic from technical frameworks.
Discussion on code structuring, design styles, and references related to Domain Driven Design and Hexagonal Architecture.
More Related Content
Similar to Domain Driven Design & Hexagonal Architecture
Domain Driven Design & Hexagonal Architecture
- 1. Domain Driven Design & HexagonalArchitecture Handling Complex Business Logic Can Pekdemir
- 2. About me Expert SoftwareEngineer @iyzico Dokuz Eylul University – Computer Science – 2010 Worked as consultancy in various domains like finance, e-commerce, telecom Speaking at meetups rarely
- 3. The term Domain DrivenDesign: Tackling Complexity in the Heart of Software, Eric Evans, 2003
- 4. Our Biggest Problems GrowingComplexity Time to Market
- 5. General problems insw development Thinking software development as a cost center rather than a profit center Heavy usage of the latest sexy framework all cool kids talk about Poor collaboration with the business Not giving real emphasis to naming things Wrong abstractions and generalizing solutions unnecessarily by thinking about 5 years later
- 6. Domain Driven Design Anapproach for solving complex business problems A mindset of developing business not only software Helps team organization, enterprise architecture, code design Cope with technology challenges ( e.g. Enterprise frameworks, NoSql, Microservices)
- 7. Big ball ofmud
- 8. Exploring the domainwith collaboration
- 9. Hands-on Modelers People whowrite the code should feel responsible for the model. A modeler should not be separated from implementation.
- 10. Ubiquitous Language One team,one language No need for translation Use in both communication and in the code
- 11. Bounded Context A semanticcontextual boundary Divide large system into autonomous contexts Be explicit about the context responsibilities Set boundaries and relationships with each other Care about team organization, code bases, database schemas
- 12. Make sense ofBounded Contexts for your company
- 13. Strategic Design withBounded Context Started as a monolithic application More teams operated on the same application Ownership began to blur Shared resources were making it difficult to scale-out “the traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it.” Werner Vogels, CTO, Amazon, 2006 http://queue.acm.org/detail.cfm?id=1142065
- 14. Real Numbers Over 6000employees In 400 cities and 70 countries From 200 engineers to 2000 Engineers only in a year and half 8000 git repositories Over 1000 microservices https://www.youtube.com/watch?v=kb-m2fasdDY What I Wish I Had Known Before Scaling Uber to 1000 Services - Matt Ranney “Scaling the traffic is not the issue. Scaling the team and the product feature release rate is the primary driver.”
- 15. Context Mapping • Strategicdomain driven design • Very useful tool to understand overall architecture and relationships of the system.
- 16. Relations of BoundedContexts
- 17. Anti Corruption Layers Protectyour own domain from the dependent contexts Translate unrelated namings into your own domain Protect yourself from others’ failures with timeouts and circuit breakers
- 18. Integrate Bounded Contextswith Restful API See your API from the consumer’s eyes Do not reflect your entities to restful resources directly Use consumer driven contract libraries ( e.g. PACT, Spring Cloud Contracts )
- 19. Integrate Bounded Contextswith Messaging Design your domain events regarding your business logic Use at-least-once delivery messaging mechanism Be careful about your receivers to idempotent
- 20. Aggregates Compose entities andvalue objects and mark one entity as root Apply consistency boundaries within aggregates Modify and commit only one aggregate instance in one transaction Hint for microservices
- 21.
- 22. Aggregate Design Rules Donot let your business logic inside an aggregate leak Design small aggregates Reference by identity only Update other aggregates by eventual consistency ( optional for scalability )
- 23. Domain Events A recordof some business-significant occurence in bounded context Append-only event store mechanisms can be implemented
- 24. Organize your Code BaklavaCode Code with too many layers
- 25. Hexagonal Architecture Technology freeDomain Model “Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.” Alistair Cockburn – 2005 Decide on what is inside and outside
- 26. Benefits Abstracts your businesscode from technical frameworks Helps you to change your architectural decisions easily Helps doing BDD and TDD
- 27.
- 28.
- 29. References Books - Domain DrivenDesign: Tackling Complexity in the Heart of Software - Domain Driven Design Distilled - Implementing Domain Driven Design - Building Microservices Links - http://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html - http://alistair.cockburn.us/Hexagonal+architecture - https://www.johndcook.com/blog/2009/07/27/baklav-code/