Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Implementing
Domain Driven Design (DDD)
a practical guide
https://github.com/hikalkan/presentations
ABOUT ME
Halil İbrahim Kalkan
Web: halilibrahimkalkan.com
Github: @hikalkan
Twitter: @hibrahimkalkan
Co-Founder of
ASP.NET BOILERPLATE
6+ years continuous development
7.000+ stars on GitHub
1.500.000+ downloads on NuGet
https://aspnetboi...
Agenda
• Part-I: What is DDD?
• Architecture & layers
• Execution flow
• Building blocks
• Common principles
• Part-II: Im...
Part-I: What is DDD?
What is DDD?
• Domain-driven design (DDD) is an approach to
software development for complex needs by
connecting the imple...
Domain Driven Design
Layers & Clean Architecture
Infrastructure
Layer
Presentation Layer
Application Layer
Domain Layer
Domain Driven Design
Core Building Blocks
Domain Layer
• Entity
• Value Object
• Aggregate & Aggregate Root
• Repository
•...
Domain Driven Design
Layering in Visual Studio
Application Layer
Domain Layer
Infrastructure Layer
Presentation Layer
Test...
Domain Driven Design
Layering in Visual Studio
Domain.SharedDomain
App.ContractsApplication
Web
Infrastructure / EntityFra...
Domain Driven Design
Execution Flow
Application
Services
Domain Services
Entities
Repositories
(interface)
HTTP API
MVC UI...
Domain Driven Design
Common Principles
• Database / ORM independence
• Presentation technology agnostic
• Doesn’t care abo...
Part-II: Implementation
Implementing Domain Driven Design (DDD)
Aggregates
Example
Guid Id
--------------------------------------
string Text
bool IsClosed
Enum CloseReason
-------------...
Aggregate Roots
Principles
• Saved & retrieved as a single unit
(with all sub-collections & all
properties)
• Should maint...
Aggregate Roots
Rule: Reference Other Aggregates only by Id
• Don’t define collections to other
aggregates!
• Don’t define...
Aggregate Roots
Tip: Keep it small
Considerations;
• Objects used together
• Query Performance
• Data Integrity & Validity
Aggregate Roots / Entities
Primary Keys
Aggregate Root
Define a single Primary Key (Id)
Entity
Can define a composite Prim...
Aggregate Roots & Entities
Constructor
• Force to create a VALID entity
• Get minimum required arguments
• Check validity ...
Aggregate Roots & Entities
Property Accessors & Methods
• Maintain object validity
• Use private setters when needed
• Cha...
Aggregate Roots & Entities
Business Logic & Exceptions
• Implement Business Rules
• Define and throw specialized
exceptions
Aggregate Roots & Entities
Business Logic Requires External Services
• How to implement when you need external services?
•...
Aggregate Roots & Entities
Business Logic Requires External Services
• How to implement when you need external services?
•...
Repositories
Principles
• A repository is a collection-like interface to interact with the database
to read and write enti...
Repositories
Do not Include Domain Logic
What is an In-Active issue?
Repositories
Do not Include Domain Logic
• Implicit definition of a
domain rule!
• How to re-use this
expression?
Repositories
Do not Include Domain Logic
• Implicit definition of a
domain rule!
• How to re-use this
expression?
• Copy/p...
Specifications
Specification Interface
• A specification is a named, reusable & combinable class to filter
objects.
Specifications
Specification Interface
• A specification is a named, reusable & combinable class to filter
objects.
Specifications
Base Specification Class
Specifications
Define a Specification
Specifications
Use the Specification
Specifications
Use the Specification
Specifications
Combining Specifications
Specifications
Combining Specifications
Domain Services
Principles
• Implements domain logic that;
• Depends on services and repositories
• Needs to work with mul...
Domain Services
Example
Business Rule: Can not assign more than 3 issues to a user
Domain Services
Example
Application Services
Principles
• Implement use cases of the application (application logic)
• Do not implement core domai...
Application Services
Example • Inject domain services & repositories
• Get DTO as argument
• Get aggregate roots from repo...
Application Services
Common DTO Principles Best Practices
• Should be serializable
• Should have a parameterless construct...
Application Services
Input DTO Best Practices
• Define only the properties needed for the use case
• Do not reuse same inp...
Application Services
Input DTO Best Practices
• Define only the properties needed for the use case
• Do not reuse same inp...
Application Services
Input DTO Best Practices
• Implement only the formal validation (can use data annotation attributes)
...
Application Services
Output DTO suggestions
• Keep output DTO count minimum. Reuse where possible (except input DTOs as ou...
Application Services
Output DTO suggestions
Application Services
Object to Object Mapping
• Use auto object mapping libraries (but, carefully – enable configuration
v...
Application Services
Example: Entity Creation & DTO Mapping
• Don’t use DTO to entity auto-
mapping, use entity constructo...
Multiple Application Layers
Domain Layer
Back Office Application
Layer
Public Web Application
Layer
Mobile Application
Lay...
Application Logic & Domain Logic
Examples..?
Business Logic
Application Logic
(Use Cases)
Domain Logic
Application Logic & Domain Logic
• Don’t create domain services to perform
simple CRUD operations!
• Use Repositories in t...
Application Logic & Domain Logic
• Domain service should check
duplicate organization name.
• Domain service doesn’t perfo...
Application Logic & Domain Logic
• Application service methods should be a unit of
work (transactional) if contains more t...
Reference Books
Domain Driven Design
Eric Evans
Implementing
Domain Driven Design
Vaughn Vernon
Clean Architecture
Robert ...
Thanks..! Questions..?
Halil İbrahim Kalkan
• http://halilibrahimkalkan.com
• GitHub @hikalkan
• Twitter @hibrahimkalkan
P...
Upcoming SlideShare
Loading in …5
×

of

.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 1 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 2 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 3 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 4 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 5 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 6 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 7 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 8 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 9 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 10 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 11 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 12 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 13 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 14 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 15 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 16 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 17 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 18 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 19 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 20 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 21 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 22 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 23 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 24 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 25 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 26 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 27 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 28 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 29 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 30 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 31 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 32 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 33 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 34 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 35 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 36 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 37 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 38 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 39 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 40 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 41 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 42 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 43 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 44 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 45 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 46 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 47 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 48 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 49 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 50 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 51 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 52 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 53 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 54 .NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design Slide 55
Upcoming SlideShare
What to Upload to SlideShare
Next

2 Likes

Share

.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design

“Domain Driven Design is an approach to software development for complex needs by connecting the implementation to an evolving model.”
While there are many resources on the web about the DDD, they are generally theoretical rather than useful practical guides. One reason is that a DDD implementation quite varies depending on your domain and culture. However, it is still possible to provide some explicit rules those can help you while designing your code base.
This talk starts by introducing the DDD and providing a layering model based on the DDD and the Clean Architecture. It then introduces the core building of an application built on the DDD principles.
In the second part of the talk, it shows some strict coding rules for the core building blocks with real code examples and suggestions. These rules are essential to build a large scale application implements DDD patterns & practices.
While the solution structure and code samples are based on .NET and C#, the talk is useful for developers and architects working with any server side technology.

Related Audiobooks

Free with a 30 day trial from Scribd

See all

.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design

  1. 1. Implementing Domain Driven Design (DDD) a practical guide https://github.com/hikalkan/presentations
  2. 2. ABOUT ME Halil İbrahim Kalkan Web: halilibrahimkalkan.com Github: @hikalkan Twitter: @hibrahimkalkan Co-Founder of
  3. 3. ASP.NET BOILERPLATE 6+ years continuous development 7.000+ stars on GitHub 1.500.000+ downloads on NuGet https://aspnetboilerplate.com
  4. 4. Agenda • Part-I: What is DDD? • Architecture & layers • Execution flow • Building blocks • Common principles • Part-II: Implementing DDD • Layering a Visual Studio solution • Rules & Best Practices • Examples
  5. 5. Part-I: What is DDD?
  6. 6. What is DDD? • Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model • Focuses on the core domain logic rather than the infrastructure. • Suitable for complex domains and large-scale applications. • Helps to build a flexible, modular and maintainable code base, based on the Object Oriented Programming principles.
  7. 7. Domain Driven Design Layers & Clean Architecture Infrastructure Layer Presentation Layer Application Layer Domain Layer
  8. 8. Domain Driven Design Core Building Blocks Domain Layer • Entity • Value Object • Aggregate & Aggregate Root • Repository • Domain Service • Specification • … Application Layer • Application Service • Data Transfer Object (DTO) • Unit of Work • …
  9. 9. Domain Driven Design Layering in Visual Studio Application Layer Domain Layer Infrastructure Layer Presentation Layer Test Projects • Domain.Shared • IssueConsts • IssueType (enum) • Domain • Issue • IssueManager • IIssueRepository • Application.Contracts • IIssueAppService • IssueDto, IssueCreationDto • Application • IssueAppService (implementation) • Infrastructure / EntityFrameworkCore • EfCoreIssueRepository • MyDbContext • Web • IssueController • IssueViewModel • Issues.cshtml • Issues.js
  10. 10. Domain Driven Design Layering in Visual Studio Domain.SharedDomain App.ContractsApplication Web Infrastructure / EntityFrameworkCore
  11. 11. Domain Driven Design Execution Flow Application Services Domain Services Entities Repositories (interface) HTTP API MVC UIBrowsers Remote clients DTO DTO HTTP request HTTP request HTML/JSON/js/css JSON DOMAIN layerAPPLICATION layerPRESENTATION layer Distributed Services Layer Authorization Validation Exception Handling Audit Logging Caching Authorization Validation Audit Logging Unit of Work / DB Transaction C R O S S C U T T I N G C O N C E R N S
  12. 12. Domain Driven Design Common Principles • Database / ORM independence • Presentation technology agnostic • Doesn’t care about reporting / mass querying • Focuses on state changes of domain objects
  13. 13. Part-II: Implementation Implementing Domain Driven Design (DDD)
  14. 14. Aggregates Example Guid Id -------------------------------------- string Text bool IsClosed Enum CloseReason -------------------------------------- Guid RepositoryId Guid AssignedUserId -------------------------------------- ICollection<Comment> ICollection<IssueLabel> Issue (aggregate root) Guid IssueId Guid LabelId IssueLabel (value obj) Guid Id -------------------------------------- string Text DateTime CreationTime -------------------------------------- Guid IssueId Guid UserId Comment (entity) Guid Id -------------------------------------- string Name … … Repository (agg. root) Guid Id -------------------------------------- string UserName string Password … User (agg. root) Guid Id -------------------------------------- string Name string Color … Label (agg. root) Guid Id -------------------------------------- … … Other (entity) Issue Aggregate Repository Aggregate User Aggregate Label Aggregate
  15. 15. Aggregate Roots Principles • Saved & retrieved as a single unit (with all sub-collections & all properties) • Should maintain self integrity & validity by implementing domain rules & constraints • Responsible to manage sub entities/objects • An aggregate is generally considered as a transaction boundary. • Should be serializable (already required for NoSQL databases)
  16. 16. Aggregate Roots Rule: Reference Other Aggregates only by Id • Don’t define collections to other aggregates! • Don’t define navigation property to other aggregates! • Reference to other aggregate roots by Id.
  17. 17. Aggregate Roots Tip: Keep it small Considerations; • Objects used together • Query Performance • Data Integrity & Validity
  18. 18. Aggregate Roots / Entities Primary Keys Aggregate Root Define a single Primary Key (Id) Entity Can define a composite Primary Key Suggestion: Prefer GUID as the PK
  19. 19. Aggregate Roots & Entities Constructor • Force to create a VALID entity • Get minimum required arguments • Check validity of inputs • Initialize sub collections • Create a private default constructor for ORMs & deserialization • Tip: Get id as an argument, don’t use Guid.NewGuid() inside the constructor • Use a service to create GUIDs
  20. 20. Aggregate Roots & Entities Property Accessors & Methods • Maintain object validity • Use private setters when needed • Change properties via methods
  21. 21. Aggregate Roots & Entities Business Logic & Exceptions • Implement Business Rules • Define and throw specialized exceptions
  22. 22. Aggregate Roots & Entities Business Logic Requires External Services • How to implement when you need external services? • Business Rule: Can not assign more than 3 issues to a user!
  23. 23. Aggregate Roots & Entities Business Logic Requires External Services • How to implement when you need external services? • Business Rule: Can not assign more than 3 issues to a user! ALTERNATIVE..? Create a Domain Service!
  24. 24. Repositories Principles • A repository is a collection-like interface to interact with the database to read and write entities • Define interface in the domain layer, implement in the infrastructure • Do not include domain logic • Repository interface should be database / ORM independent • Create repositories for aggregate roots, not entities
  25. 25. Repositories Do not Include Domain Logic What is an In-Active issue?
  26. 26. Repositories Do not Include Domain Logic • Implicit definition of a domain rule! • How to re-use this expression?
  27. 27. Repositories Do not Include Domain Logic • Implicit definition of a domain rule! • How to re-use this expression? • Copy/paste? • Solution: The Specification Pattern!
  28. 28. Specifications Specification Interface • A specification is a named, reusable & combinable class to filter objects.
  29. 29. Specifications Specification Interface • A specification is a named, reusable & combinable class to filter objects.
  30. 30. Specifications Base Specification Class
  31. 31. Specifications Define a Specification
  32. 32. Specifications Use the Specification
  33. 33. Specifications Use the Specification
  34. 34. Specifications Combining Specifications
  35. 35. Specifications Combining Specifications
  36. 36. Domain Services Principles • Implements domain logic that; • Depends on services and repositories • Needs to work with multiple entities / entity types • Works with domain objects, not DTOs
  37. 37. Domain Services Example Business Rule: Can not assign more than 3 issues to a user
  38. 38. Domain Services Example
  39. 39. Application Services Principles • Implement use cases of the application (application logic) • Do not implement core domain logic • Get & return Data Transfer Objects, not entities • Use domain services, entities, repositories and other domain objects inside
  40. 40. Application Services Example • Inject domain services & repositories • Get DTO as argument • Get aggregate roots from repositories • Use domain service to perform the domain logic • Always update the entity explicitly (don’t assume the change tracking)
  41. 41. Application Services Common DTO Principles Best Practices • Should be serializable • Should have a parameterless constructor • Should not contain any business logic • Never inherit from entities! Never reference to entities!
  42. 42. Application Services Input DTO Best Practices • Define only the properties needed for the use case • Do not reuse same input DTO for multiple use cases (service methods) • Id is not used in create! Do not share same DTO for create & update! • Password is not used in Update and ChangeUserName! • CreationTime should not be sent by the client!
  43. 43. Application Services Input DTO Best Practices • Define only the properties needed for the use case • Do not reuse same input DTO for multiple use cases (service methods)
  44. 44. Application Services Input DTO Best Practices • Implement only the formal validation (can use data annotation attributes) • Don’t include domain validation logic (ex: unique user name constraint)
  45. 45. Application Services Output DTO suggestions • Keep output DTO count minimum. Reuse where possible (except input DTOs as output DTO). • Can contain more properties than client needs • Return the entity DTO from Create & update methods. • Exception: Where performance is critical, especially for large result sets.
  46. 46. Application Services Output DTO suggestions
  47. 47. Application Services Object to Object Mapping • Use auto object mapping libraries (but, carefully – enable configuration validation) • Do not map input DTOs to entities. • Map entities to output DTOs
  48. 48. Application Services Example: Entity Creation & DTO Mapping • Don’t use DTO to entity auto- mapping, use entity constructor. • Perform additional domain actions. • Use repository to insert the entity. • Return DTO using auto-mapping.
  49. 49. Multiple Application Layers Domain Layer Back Office Application Layer Public Web Application Layer Mobile Application Layer Mobile APIMVC UIREST API SPA Browser Mobile App • Create separate application layers for each application type. • Use a single domain layer to share the core domain logic.
  50. 50. Application Logic & Domain Logic Examples..? Business Logic Application Logic (Use Cases) Domain Logic
  51. 51. Application Logic & Domain Logic • Don’t create domain services to perform simple CRUD operations! • Use Repositories in the application services. • Never pass DTOs to or return DTOs from domain services! • DTOs should be in the application layer.
  52. 52. Application Logic & Domain Logic • Domain service should check duplicate organization name. • Domain service doesn’t perform authorization! • Do in the application layer! • Domain service must not depend on the current user! • Do in the application/UI/API layer! • Domain service must not send email that is not related to the actual business! • Do in the application layer or implement via domain events.
  53. 53. Application Logic & Domain Logic • Application service methods should be a unit of work (transactional) if contains more than one database operations. • Authorization is done in the application layer. • Payment (infrastructure service) and Organization creation should not be combined in the domain layer. Should be orchestrated by the application layer. • Email sending can be done in the application service. • Do not return entities from application services! • Why not moving payment logic inside the domain service?
  54. 54. Reference Books Domain Driven Design Eric Evans Implementing Domain Driven Design Vaughn Vernon Clean Architecture Robert C. Martin
  55. 55. Thanks..! Questions..? Halil İbrahim Kalkan • http://halilibrahimkalkan.com • GitHub @hikalkan • Twitter @hibrahimkalkan Presentation: https://github.com/hikalkan/presentations
  • powerirs

    Jun. 28, 2020
  • PhuocLe38

    Mar. 4, 2020

“Domain Driven Design is an approach to software development for complex needs by connecting the implementation to an evolving model.” While there are many resources on the web about the DDD, they are generally theoretical rather than useful practical guides. One reason is that a DDD implementation quite varies depending on your domain and culture. However, it is still possible to provide some explicit rules those can help you while designing your code base. This talk starts by introducing the DDD and providing a layering model based on the DDD and the Clean Architecture. It then introduces the core building of an application built on the DDD principles. In the second part of the talk, it shows some strict coding rules for the core building blocks with real code examples and suggestions. These rules are essential to build a large scale application implements DDD patterns & practices. While the solution structure and code samples are based on .NET and C#, the talk is useful for developers and architects working with any server side technology.

Views

Total views

1,307

On Slideshare

0

From embeds

0

Number of embeds

1

Actions

Downloads

0

Shares

0

Comments

0

Likes

2

×