Domain Driven Design

2,603 views
2,312 views

Published on

What is Domain Drive Design.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,603
On SlideShare
0
From Embeds
0
Number of Embeds
19
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Introduction Knowledge of DDD?
  • What is small system? Need to change design if system grows
  • Entity – objects with a distinct identity. Core of domain model. ValueObject – objects that are primarily defined by the value of their attributes. Often immutable. Two instances whose attributes have the same values can be used interchangeably. Service – implement the workflow of the application. Fulfill a use case. Generally include behaviors that cannot be assigned to a single entity and consist of methods that act on multiple objects. Can be in domain, infrastructure or application level.
  • Facade – hides complexities of accessing domain model. Like application level services. Define use cases. Contain no business logic themselves. Specification – need to check that only suitable objects are used for a certain role. Keep business rules inside the domain model not leak it out into application layer. If there is large collection it can be same as Query object. Repository – manage collections of entities and define methods for finding and deleting entities. So that clients don't have to care where entities are coming from. Other == DAO but in can be special cases like query some stuff first from some service and then from db. Factory – for creating NEW complex entities. Not like Repositories.
  • Domain Driven Design

    1. 1. Introduction to Domain Driven Design <ul><ul><li>Aqris Software </li></ul></ul><ul><ul><li>Ürgo Ringo </li></ul></ul>
    2. 2. Sample use case – enter activity <ul><ul><li>Basic flow </li></ul></ul><ul><ul><li>User wants to enter new activity. System displays new form where some fields have been filled based on last entered activity. User enters activity and submits form. System validates and adds activity into persistence storage if it's valid. </li></ul></ul><ul><ul><li>Business rules </li></ul></ul><ul><ul><li>- activity description must not be empty </li></ul></ul><ul><ul><li>- activity must start before it ends </li></ul></ul><ul><ul><li>- activity duration must not overlap with existing ones </li></ul></ul><ul><ul><li>- JIRA key must exist in JIRA </li></ul></ul>
    3. 3. “Domain Model” - non-DDD way UML class diagram
    4. 4. Show form - non-DDD way <ul><ul><li>UML sequence diagram </li></ul></ul>
    5. 5. Submit form – non-DDD way UML sequence diagram
    6. 6. Benefits of non-DDD way <ul><li>easy to learn </li></ul><ul><li>simple OR mapping </li></ul><ul><li>easier to avoid performance problems Good for small systems(?) </li></ul>
    7. 7. Problems of non-DDD way <ul><li>procedural implementation </li></ul><ul><li>anemic domain model </li></ul><ul><li>boilerplate service layer </li></ul><ul><li>fat controllers Expensive to develop/maintain </li></ul>
    8. 8. How to improve design <ul><ul><li>Using ideas of DDD and Domain Model </li></ul></ul><ul><ul><li>Domain Driven Design – E. Evans </li></ul></ul><ul><ul><li>Patterns of Enterprise Application Architecture – M. Fowler </li></ul></ul>
    9. 9. What is DDD (1) <ul><li>Entity e.g Activity, Project, User </li></ul><ul><li>ValueObject e.g Duration, Address </li></ul><ul><li>Service e.g JiraService, EmailNotificationService, TransferService </li></ul>
    10. 10. What is DDD (2) <ul><li>Facade e.g EnterActivityFacade, ViewActivitiesReportFacade </li></ul><ul><li>Specification e.g ActivityDurationSpecification, UsernameSpecification </li></ul><ul><li>Repository e.g ActivityRepository, ProjectRepository </li></ul><ul><li>Factory e.g ActivityFactory </li></ul>
    11. 11. Domain Model - DDD way UML class diagram
    12. 12. Show form - DDD way UML sequence diagram
    13. 13. Submit form - DDD way UML sequence diagram

    ×