Downloaded 108 times
Uploaded byCrishantha Nanayakkara
Domain Driven Design and Hexagonal Architecture
The document discusses Domain Driven Design (DDD) and the Hexagonal Architecture. It describes DDD concepts like bounded contexts, core domains, ubiquitous language, and aggregates. It also explains different types of context mapping. The Hexagonal Architecture separates an application into three main parts - the domain model, ports, and adapters. Ports define application interfaces while adapters act as bridges between the application and external interfaces or services.
More Related Content
Similar to Domain Driven Design and Hexagonal Architecture
Domain Driven Design and Hexagonal Architecture
- 1.
- 2.
- 3.
- 4.
- 5. 5 Bounded Context ● It is a “Strategic Design Pattern”. ● It describes a “Semantic Contextual Boundary”. –Within the boundary, each component of the software model has a specific meaning and does specific things.
- 6. 6 Core Domain(s) ● An Enterprise consists of multiple “Core Domain(s)” ● Core Domain = Bounded Context ●The boundary is completely determined by the Core Domain owner ● Each Core Domain / Bounded Context, consists of – A source code repository – A database – Set of Concepts
- 7.
- 8.
- 9.
- 10.
- 11. 11 Ubiquitous Language ● In DDD, finding the correct Ubiquitous Language is important to find the “In Context” and the “Out Context” ● It is not about finding only nouns in the context ●It is about finding the scenarios in the context ● Scenarios are not the typical use cases that you find in the OOD
- 12. 12 ● In a DDD project, there can be multiple “Bounded Contexts”. ● In a DDD project, a “Bounded Context” should align 1:1 with a single “Sub Domain” ●A “Sub Domain” is a subpart of your overall business domain. ● There are three primary types of Sub Domains in an Enterprise. – Core Domain – Supporting Domain – Generic Domain Sub Domains
- 13.
- 14.
- 15. 15 ● Partnership ● Shared Kernel ●CustomerSupplier ● Conformist ● Anticorruption Layer ● Open Host Service ● Published Language ● Separate Ways Context Mapping Types
- 16. 16 ● Partnership – Two teams create a partnership with a dependent set of goals –Two teams will succeed or fail together – The partnership will succeed as long as the commitment lies between both parties Context Mapping Types
- 17. 17 ● Shared Kernel – Two teams share a small but a common model –Often difficult to manage Context Mapping Types
- 18. 18 ● CustomerSupplier – Supplier (Upstream); Customer (Downstream) –Supplier decides what the customer gets Context Mapping Types
- 19. 19 ● Conformist – A CustomerSupplier type –Downstream model should conform to the Upstream model always Context Mapping Types
- 20.
- 21. 21 ● Open Host Service / Published Language – The host defines the interface as an API and it can be consumed by any customer –This is a much better method compared to others – The “Published Language” is when you are using a standard interface, such as WSDL or JSON Context Mapping Types
- 22.
- 23. 23 Aggregate ● There are two Bounded Contexts here ● Each Bounded Context has got multiple Aggregates –e.g. The “Product”, “Backlog Item”, “Release”, “Sprint” are aggregates on the left Bounded Context
- 24. 24 ● Aggregate is a pattern in DDD, which is a cluster of domain objects that can be treated as a single unit ● One of its component objects be the “aggregate root” ●The aggregate root can ensure the integrity of the aggregate as a whole Aggregate
- 25. 25 ● Each aggregate forms a transactional consistency boundary ● Only one aggregate should be committed in a single transaction (The general rule in the aggregate design) ●Any other aggregate should be committed in a separate transaction Aggregate
- 26. 26 ● Design Small Aggregates and eliminate large aggregates ● Smaller aggregates are easier to work on and scalable ●Follows the SRP (Single Responsibility Principle) Aggregate
- 27. 27 ● Reference other aggregates by Identity only. Helps to keep Aggregates small and prevents reaching out to modify multiple aggregates in the same transaction ● Lower memory requirement and quicker loading from the persistent store ●Facilitates multiple persistence stores such as Relational Databases, Document Databases, Key Value Stores Aggregate
- 28.
- 29.
- 30.
- 31. 31 The Hexagonal Architecture (Ports and Adapters) ● This is known as the fundamental architecture in DDD. ● It is an “Architecture Style”, also known as the “Ports and Adapters” ●An extension to the traditional “layered architecture”, which has one directional thinking and mostly all the dependencies go in one direction ● It talks about the distinction between the softwares’ inside and outside parts – Inside Part: the Domain model – Outside Part : UI, Database and Messaging
- 32. 32 The Three Components ● There are 3 main components – Domain Model –Ports – Adapters ● Domain Model – A conceptual model, a representation of meaningful concepts to the domain that need to be modeled in software
- 33. 33 The Three Components ● Ports – Primary Ports ●Main APIs/ Interfaces of the application. ● They are called by the Primary Adapters – Secondary Ports ● APIs/ Interfaces for the Secondary Adapters ● They are called by the Core Logic
- 34. 34 The Three Components ● Adapter is a bridge between the application and the port / service ● Adapters –Primary Adapter – A piece of code between the user and the core logic and interact with the Primary port – Secondary Adapter – Interacts with the Secondary port
- 35.
- 36.
- 37. 37 References ● Domain DrivenDesign Distilled – By Vaughn Vernon ● https://www.thoughtworks.com/insights/blog/domain-driven-design-se rvices-architecture ● https://dzone.com/refcardz/getting-started-domain-driven
- 38.