.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
- 1. Implementing Domain Driven Design (DDD) a practical guide https://github.com/hikalkan/presentations
- 2. ABOUT ME Halil İbrahim Kalkan Web: halilibrahimkalkan.com Github: @hikalkan Twitter: @hibrahimkalkan Co-Founder of
- 3. ASP.NET BOILERPLATE 6+ years continuous development 7.000+ stars on GitHub 1.500.000+ downloads on NuGet https://aspnetboilerplate.com
- 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. Part-I: What is DDD?
- 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. Domain Driven Design Layers & Clean Architecture Infrastructure Layer Presentation Layer Application Layer Domain Layer
- 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. 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. Domain Driven Design Layering in Visual Studio Domain.SharedDomain App.ContractsApplication Web Infrastructure / EntityFrameworkCore
- 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. 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. Part-II: Implementation Implementing Domain Driven Design (DDD)
- 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. 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. 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. Aggregate Roots Tip: Keep it small Considerations; • Objects used together • Query Performance • Data Integrity & Validity
- 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. 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. Aggregate Roots & Entities Property Accessors & Methods • Maintain object validity • Use private setters when needed • Change properties via methods
- 21. Aggregate Roots & Entities Business Logic & Exceptions • Implement Business Rules • Define and throw specialized exceptions
- 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. 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. 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. Repositories Do not Include Domain Logic What is an In-Active issue?
- 26. Repositories Do not Include Domain Logic • Implicit definition of a domain rule! • How to re-use this expression?
- 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. Specifications Specification Interface • A specification is a named, reusable & combinable class to filter objects.
- 29. Specifications Specification Interface • A specification is a named, reusable & combinable class to filter objects.
- 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. Domain Services Example Business Rule: Can not assign more than 3 issues to a user
- 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. 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. 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. 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. 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. 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. 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. Application Services Output DTO suggestions
- 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. 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. 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. Application Logic & Domain Logic Examples..? Business Logic Application Logic (Use Cases) Domain Logic
- 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. 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. 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. Reference Books Domain Driven Design Eric Evans Implementing Domain Driven Design Vaughn Vernon Clean Architecture Robert C. Martin
- 55. Thanks..! Questions..? Halil İbrahim Kalkan • http://halilibrahimkalkan.com • GitHub @hikalkan • Twitter @hibrahimkalkan Presentation: https://github.com/hikalkan/presentations