SlideShare uma empresa Scribd logo
1 de 33
Introduction to
Domain-Driven Design
Speaker



               Eduards Sizovs
Software Architect at 4finance
               - linkedin/in/eduardsi
        - eduards.sizovs@gmail.com
Agenda
•   What is DDD
•   Principles
•   Benefits
•   Why people do not use DDD
•   Building blocks
•   How to start
What is DDD
• DDD – approach to developing software where
  application’s domain model reflects real business
  model and core domain is the primary project focus




 domain.compareTo(technology) >      0
Close creative collaboration
•   Team + Domain Experts works together
•   Chaotic info is transformed into practical model
•   Model is continuously distilled and refined
•   It’s not just quizing for requirements
Common (Ubiquitous) language
• Model is based on Ubiquitous Language



                  (UL)

                 Model
 Team                            Customer
UL example (user story)
• Bad: When user logs in using valid data, his
  active credits are displayed

• Good: When borrower logs in using valid
  credentials, his open loans are displayed
Example
•   User user = userFactory.newInstance();
•   userService.register(user);
•   Application application;
•   Loan loan = loanService.takeCredit(application, user);
•   if (loan != null) { ...


   User user = userFactory.newUser();
   user.register();
   LoanApplication application;
   Loan loan = user.applyForLoan(application);
   if (application.rejected()) …
Natural refinement


If sophisticated can easily
   That way we domain experts
 do notweaknesses in the
    find understand the model,
 there is something wrong with
        domain model
            the model
Domain encapsulation
• Focus on specific business operation (e.g. Loans)
• Isolation from other domains (Loans from Credit
  Bureau)
• Isolated from other layers (UI, integration)
• Loose coupling with external dependencies (anti-
  corruption layer)
Technical simplicity
• No heavyweight framework dependencies
• POJOlicious design
Domain’s richness
• Domain is a rich model of entities, relations, rules
  and conditions, not just a data carrying entities
Benefits
• Ubiquitous Language in communication, requirements,
  specification, domain model, tests
• Common model that the team can use to communicate about
  business requirements
• The model is modular, extensible and easy to maintain
• Business model is encapsulated in one place
• Model is easy testable based on real business scenarios
• Final Code = Domain specification
If you do not follow DDD
• Likely you will have a fat service layer with anemic
  domain model
• Domain rules and business logic are scattered in
  many helpers and facades
• Harder to react to business requirement changes
• Communication is difficult
From PEAA
Anemic Domain Model
• Common architectural anti-pattern
• Violates basic OO principle – encapsulation
• “Service-driven DTOs”
Why people do not use DDD
• Complex component model with layering
  enforcements (EJB 2.*)
• Easier to grasp with development with no prior
  analysis (ad hoc development)
• Adapted to anemic domain model
• No access to domain experts
• No iterative development process
• Unwillingness to understand new domains
• Lack of good examples
Why people do not use DDD
• Clinging to technical things and frameworks
• DDD requires good OOA&D skills
• Thinking in terms of Computing
Building blocks
Entity
• An object defined primarily by its identity
• May have multiple representations
• Distinguished from another entity even both might
  have the same attributes

• Example: Customer, Book, Vehicle
• Example: Two deposit transactions
Value Object
• An object having no identity and defined by its
  attributes
• Describes state of entities
• Really powerful when built immutable

• Example: Money, Time
• Example: GPS program returns Route connecting
  Boston and Rhode Island entities
Module (or package)
•   Contains cohesive set of concepts
•   Coevolves with a model
•   Speaks UL
•   When you place some classes together in a module,
    you are telling next developer to think about them
    together
Stadium seat example
• If visitors can sit wherever they find an empty seat
  then seat is a...
• If visitors buy a ticket with a seat number on it, then
  seat is a...
Aggregate
• A collection of objects that are bound together by a
  root entity. The aggregrate root guarantees the
  consistency of changes being made within the
  aggregate by forbidding external objects from
  holding references to its members
Repository
• A contract between application and data storage,
  that speaks UL
• Pretends to be a collection of Aggregate Roots
• Repository is persistence ignorant
Example
• Payment Schedule comprises of Regular Installments
• Client pays-off Regular Installments
• Payment Schedule must be closed when all Regular
  Installments get paid
• Payment Schedule gets processed according to client
  payments
Factory
• Methods for creating domain objects should
  delegate to a specialized Factory
• Helps when entity creation is complicated or reveals
  its internal structure
• Decouples object creation from other layers
Service
• When an operation does not conceptually belong to
  an Entity nor to a Value Object you can put it in a
  service
• Services are still a natural part of a model
• Domain services should be distinguished from other
  services (application, infrastructural)
Events
• Event captures a change to the model so different
  model components can observe these changes and
  react accordingly
Specification & Function
• Entity.satisfies(Specification)
• Entity.apply(Function)



• Specification.satisfiedBy(Entity)
• Function.applyTo(Entity)
Strategic design
• Abstract Core Domain & Generic Subdomains

• Bounded Context & Context Map

• Anti-Corruption Layer
More reading
• DDD community at domaindrivendesign.org
• Books by:
  – Martin Fowler
  – Kent Beck
  – Alan Kay
  – Ward Cunningham
Thank you!

Mais conteúdo relacionado

Mais procurados

Domain Driven Design Introduction
Domain Driven Design IntroductionDomain Driven Design Introduction
Domain Driven Design Introductionwojtek_s
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven DesignAndriy Buday
 
Domain driven design
Domain driven designDomain driven design
Domain driven designits_skm
 
Domain driven design and model driven development
Domain driven design and model driven developmentDomain driven design and model driven development
Domain driven design and model driven developmentDmitry Geyzersky
 
Applying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsApplying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsAlexander van Trijffel
 
Modelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignModelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
 
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfDDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfEleonora Ciceri
 
How to Implement Domain Driven Design in Real Life SDLC
How to Implement Domain Driven Design  in Real Life SDLCHow to Implement Domain Driven Design  in Real Life SDLC
How to Implement Domain Driven Design in Real Life SDLCAbdul Karim
 
Domain Driven Design Quickly
Domain Driven Design QuicklyDomain Driven Design Quickly
Domain Driven Design QuicklyMariam Hakobyan
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
 
Introduction to Domain Driven Design
Introduction to Domain Driven DesignIntroduction to Domain Driven Design
Introduction to Domain Driven DesignChristos Tsakostas
 
Hexagonal Architecture.pdf
Hexagonal Architecture.pdfHexagonal Architecture.pdf
Hexagonal Architecture.pdfVladimirRadzivil
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichIvan Paulovich
 

Mais procurados (20)

Domain Driven Design Introduction
Domain Driven Design IntroductionDomain Driven Design Introduction
Domain Driven Design Introduction
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Domain driven design
Domain driven designDomain driven design
Domain driven design
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Domain driven design
Domain driven designDomain driven design
Domain driven design
 
Domain driven design and model driven development
Domain driven design and model driven developmentDomain driven design and model driven development
Domain driven design and model driven development
 
Applying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain ModelsApplying Domain-Driven Design to craft Rich Domain Models
Applying Domain-Driven Design to craft Rich Domain Models
 
Modelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignModelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven Design
 
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfDDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
 
How to Implement Domain Driven Design in Real Life SDLC
How to Implement Domain Driven Design  in Real Life SDLCHow to Implement Domain Driven Design  in Real Life SDLC
How to Implement Domain Driven Design in Real Life SDLC
 
Domain Driven Design Quickly
Domain Driven Design QuicklyDomain Driven Design Quickly
Domain Driven Design Quickly
 
A Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation SlidesA Practical Guide to Domain Driven Design: Presentation Slides
A Practical Guide to Domain Driven Design: Presentation Slides
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Domain driven design
Domain driven designDomain driven design
Domain driven design
 
Ddd + ah + microservicios
Ddd + ah + microserviciosDdd + ah + microservicios
Ddd + ah + microservicios
 
Introduction to Domain Driven Design
Introduction to Domain Driven DesignIntroduction to Domain Driven Design
Introduction to Domain Driven Design
 
Hexagonal Architecture.pdf
Hexagonal Architecture.pdfHexagonal Architecture.pdf
Hexagonal Architecture.pdf
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan Paulovich
 
Domain Driven Design
Domain Driven Design Domain Driven Design
Domain Driven Design
 

Destaque

Code Structural Analysis
Code Structural AnalysisCode Structural Analysis
Code Structural AnalysisEduards Sizovs
 
Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011thinkddd
 
[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장sung ki choi
 
Introducción a DDD
Introducción a DDDIntroducción a DDD
Introducción a DDDsergiopolo
 
Domain Driven Design using Laravel
Domain Driven Design using LaravelDomain Driven Design using Laravel
Domain Driven Design using Laravelwajrcs
 

Destaque (7)

SOLID
SOLIDSOLID
SOLID
 
Code Structural Analysis
Code Structural AnalysisCode Structural Analysis
Code Structural Analysis
 
Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011Domain Driven Design - DDDSydney 2011
Domain Driven Design - DDDSydney 2011
 
[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장
 
Introducción a DDD
Introducción a DDDIntroducción a DDD
Introducción a DDD
 
Domain Driven Design 101
Domain Driven Design 101Domain Driven Design 101
Domain Driven Design 101
 
Domain Driven Design using Laravel
Domain Driven Design using LaravelDomain Driven Design using Laravel
Domain Driven Design using Laravel
 

Semelhante a Introduction to DDD

Domain Driven Design - Building Blocks
Domain Driven Design - Building BlocksDomain Driven Design - Building Blocks
Domain Driven Design - Building BlocksMark Windholtz
 
Schibsted Spain - Day 1 - DDD Course
Schibsted Spain - Day 1 - DDD CourseSchibsted Spain - Day 1 - DDD Course
Schibsted Spain - Day 1 - DDD CourseKevin Mas Ruiz
 
2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use itMark Windholtz
 
An Introduction to Domain Driven Design in PHP
An Introduction to Domain Driven Design in PHPAn Introduction to Domain Driven Design in PHP
An Introduction to Domain Driven Design in PHPChris Renner
 
Domain Driven Design - Distillation - Chapter 15
Domain Driven Design - Distillation - Chapter 15Domain Driven Design - Distillation - Chapter 15
Domain Driven Design - Distillation - Chapter 15Mark Windholtz
 
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...confluent
 
Domain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsDomain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsMark Windholtz
 
Domain Driven Design Ruby Ways - JURNAL 05/10/2017
Domain Driven Design Ruby Ways -  JURNAL 05/10/2017Domain Driven Design Ruby Ways -  JURNAL 05/10/2017
Domain Driven Design Ruby Ways - JURNAL 05/10/2017Jonathan Wylliem
 
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...confluent
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableComsysto Reply GmbH
 
Software development planning and essentials
Software development planning and essentialsSoftware development planning and essentials
Software development planning and essentialsRajesh P
 
Software development planning and essentials
Software development planning and essentialsSoftware development planning and essentials
Software development planning and essentialsRajesh P
 
Weekly Meeting: Basic Design Pattern
Weekly Meeting: Basic Design PatternWeekly Meeting: Basic Design Pattern
Weekly Meeting: Basic Design PatternNguyen Trung Kien
 
Oracle Forms Modernization Roadmap
Oracle Forms Modernization RoadmapOracle Forms Modernization Roadmap
Oracle Forms Modernization RoadmapKai-Uwe Möller
 
Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...HostedbyConfluent
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyComsysto Reply GmbH
 
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven DesignNETFest
 
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...Dell World
 

Semelhante a Introduction to DDD (20)

Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Domain Driven Design - Building Blocks
Domain Driven Design - Building BlocksDomain Driven Design - Building Blocks
Domain Driven Design - Building Blocks
 
Schibsted Spain - Day 1 - DDD Course
Schibsted Spain - Day 1 - DDD CourseSchibsted Spain - Day 1 - DDD Course
Schibsted Spain - Day 1 - DDD Course
 
2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it2019-Nov: Domain Driven Design (DDD) and when not to use it
2019-Nov: Domain Driven Design (DDD) and when not to use it
 
An Introduction to Domain Driven Design in PHP
An Introduction to Domain Driven Design in PHPAn Introduction to Domain Driven Design in PHP
An Introduction to Domain Driven Design in PHP
 
Domain Driven Design - Distillation - Chapter 15
Domain Driven Design - Distillation - Chapter 15Domain Driven Design - Distillation - Chapter 15
Domain Driven Design - Distillation - Chapter 15
 
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
Designing and Implementing Information Systems with Event Modeling, Bobby Cal...
 
Domain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic PatternsDomain Driven Design Big Picture Strategic Patterns
Domain Driven Design Big Picture Strategic Patterns
 
Domain Driven Design Ruby Ways - JURNAL 05/10/2017
Domain Driven Design Ruby Ways -  JURNAL 05/10/2017Domain Driven Design Ruby Ways -  JURNAL 05/10/2017
Domain Driven Design Ruby Ways - JURNAL 05/10/2017
 
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
Building Information Systems using Event Modeling (Bobby Calderwood, Evident ...
 
Software Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuableSoftware Architecture and Architectors: useless VS valuable
Software Architecture and Architectors: useless VS valuable
 
Software development planning and essentials
Software development planning and essentialsSoftware development planning and essentials
Software development planning and essentials
 
Software development planning and essentials
Software development planning and essentialsSoftware development planning and essentials
Software development planning and essentials
 
Weekly Meeting: Basic Design Pattern
Weekly Meeting: Basic Design PatternWeekly Meeting: Basic Design Pattern
Weekly Meeting: Basic Design Pattern
 
Oracle Forms Modernization Roadmap
Oracle Forms Modernization RoadmapOracle Forms Modernization Roadmap
Oracle Forms Modernization Roadmap
 
Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...Model-driven and low-code development for event-based systems | Bobby Calderw...
Model-driven and low-code development for event-based systems | Bobby Calderw...
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
Architectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and ConsistentlyArchitectural Decisions: Smoothly and Consistently
Architectural Decisions: Smoothly and Consistently
 
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
.NET Fest 2019. Halil Ibrahim Kalkan. Implementing Domain Driven Design
 
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...
So You Need To Build A Private Cloud. What Now? Best Practices For Building Y...
 

Mais de Eduards Sizovs

Beyond Software Craftsmanship - Johnny's Road to Remarkable Career
Beyond Software Craftsmanship - Johnny's Road to Remarkable CareerBeyond Software Craftsmanship - Johnny's Road to Remarkable Career
Beyond Software Craftsmanship - Johnny's Road to Remarkable CareerEduards Sizovs
 
8 Things That Make Continuous Delivery Go Nuts
8 Things That Make Continuous Delivery Go Nuts8 Things That Make Continuous Delivery Go Nuts
8 Things That Make Continuous Delivery Go NutsEduards Sizovs
 
Architecting well-structured Java applications
Architecting well-structured Java applicationsArchitecting well-structured Java applications
Architecting well-structured Java applicationsEduards Sizovs
 
Software Architecture Anti-Patterns
Software Architecture Anti-PatternsSoftware Architecture Anti-Patterns
Software Architecture Anti-PatternsEduards Sizovs
 
Continuous Delivery (The newest)
Continuous Delivery (The newest)Continuous Delivery (The newest)
Continuous Delivery (The newest)Eduards Sizovs
 
Software Craftsmanship Essentials
Software Craftsmanship EssentialsSoftware Craftsmanship Essentials
Software Craftsmanship EssentialsEduards Sizovs
 
Micro Service Architecture
Micro Service ArchitectureMicro Service Architecture
Micro Service ArchitectureEduards Sizovs
 
Code Structural Analysis
Code Structural AnalysisCode Structural Analysis
Code Structural AnalysisEduards Sizovs
 

Mais de Eduards Sizovs (9)

Beyond Software Craftsmanship - Johnny's Road to Remarkable Career
Beyond Software Craftsmanship - Johnny's Road to Remarkable CareerBeyond Software Craftsmanship - Johnny's Road to Remarkable Career
Beyond Software Craftsmanship - Johnny's Road to Remarkable Career
 
8 Things That Make Continuous Delivery Go Nuts
8 Things That Make Continuous Delivery Go Nuts8 Things That Make Continuous Delivery Go Nuts
8 Things That Make Continuous Delivery Go Nuts
 
Architecting well-structured Java applications
Architecting well-structured Java applicationsArchitecting well-structured Java applications
Architecting well-structured Java applications
 
Software Architecture Anti-Patterns
Software Architecture Anti-PatternsSoftware Architecture Anti-Patterns
Software Architecture Anti-Patterns
 
Continuous Delivery (The newest)
Continuous Delivery (The newest)Continuous Delivery (The newest)
Continuous Delivery (The newest)
 
Software Craftsmanship Essentials
Software Craftsmanship EssentialsSoftware Craftsmanship Essentials
Software Craftsmanship Essentials
 
Micro Service Architecture
Micro Service ArchitectureMicro Service Architecture
Micro Service Architecture
 
Code Structural Analysis
Code Structural AnalysisCode Structural Analysis
Code Structural Analysis
 
Continuous Delivery
Continuous DeliveryContinuous Delivery
Continuous Delivery
 

Introduction to DDD

  • 2. Speaker Eduards Sizovs Software Architect at 4finance - linkedin/in/eduardsi - eduards.sizovs@gmail.com
  • 3. Agenda • What is DDD • Principles • Benefits • Why people do not use DDD • Building blocks • How to start
  • 4. What is DDD • DDD – approach to developing software where application’s domain model reflects real business model and core domain is the primary project focus domain.compareTo(technology) > 0
  • 5. Close creative collaboration • Team + Domain Experts works together • Chaotic info is transformed into practical model • Model is continuously distilled and refined • It’s not just quizing for requirements
  • 6. Common (Ubiquitous) language • Model is based on Ubiquitous Language (UL) Model Team Customer
  • 7. UL example (user story) • Bad: When user logs in using valid data, his active credits are displayed • Good: When borrower logs in using valid credentials, his open loans are displayed
  • 8. Example • User user = userFactory.newInstance(); • userService.register(user); • Application application; • Loan loan = loanService.takeCredit(application, user); • if (loan != null) { ...  User user = userFactory.newUser();  user.register();  LoanApplication application;  Loan loan = user.applyForLoan(application);  if (application.rejected()) …
  • 9. Natural refinement If sophisticated can easily That way we domain experts do notweaknesses in the find understand the model, there is something wrong with domain model the model
  • 10. Domain encapsulation • Focus on specific business operation (e.g. Loans) • Isolation from other domains (Loans from Credit Bureau) • Isolated from other layers (UI, integration) • Loose coupling with external dependencies (anti- corruption layer)
  • 11. Technical simplicity • No heavyweight framework dependencies • POJOlicious design
  • 12. Domain’s richness • Domain is a rich model of entities, relations, rules and conditions, not just a data carrying entities
  • 13. Benefits • Ubiquitous Language in communication, requirements, specification, domain model, tests • Common model that the team can use to communicate about business requirements • The model is modular, extensible and easy to maintain • Business model is encapsulated in one place • Model is easy testable based on real business scenarios • Final Code = Domain specification
  • 14. If you do not follow DDD • Likely you will have a fat service layer with anemic domain model • Domain rules and business logic are scattered in many helpers and facades • Harder to react to business requirement changes • Communication is difficult
  • 16. Anemic Domain Model • Common architectural anti-pattern • Violates basic OO principle – encapsulation • “Service-driven DTOs”
  • 17. Why people do not use DDD • Complex component model with layering enforcements (EJB 2.*) • Easier to grasp with development with no prior analysis (ad hoc development) • Adapted to anemic domain model • No access to domain experts • No iterative development process • Unwillingness to understand new domains • Lack of good examples
  • 18. Why people do not use DDD • Clinging to technical things and frameworks • DDD requires good OOA&D skills • Thinking in terms of Computing
  • 20. Entity • An object defined primarily by its identity • May have multiple representations • Distinguished from another entity even both might have the same attributes • Example: Customer, Book, Vehicle • Example: Two deposit transactions
  • 21. Value Object • An object having no identity and defined by its attributes • Describes state of entities • Really powerful when built immutable • Example: Money, Time • Example: GPS program returns Route connecting Boston and Rhode Island entities
  • 22. Module (or package) • Contains cohesive set of concepts • Coevolves with a model • Speaks UL • When you place some classes together in a module, you are telling next developer to think about them together
  • 23. Stadium seat example • If visitors can sit wherever they find an empty seat then seat is a... • If visitors buy a ticket with a seat number on it, then seat is a...
  • 24. Aggregate • A collection of objects that are bound together by a root entity. The aggregrate root guarantees the consistency of changes being made within the aggregate by forbidding external objects from holding references to its members
  • 25. Repository • A contract between application and data storage, that speaks UL • Pretends to be a collection of Aggregate Roots • Repository is persistence ignorant
  • 26. Example • Payment Schedule comprises of Regular Installments • Client pays-off Regular Installments • Payment Schedule must be closed when all Regular Installments get paid • Payment Schedule gets processed according to client payments
  • 27. Factory • Methods for creating domain objects should delegate to a specialized Factory • Helps when entity creation is complicated or reveals its internal structure • Decouples object creation from other layers
  • 28. Service • When an operation does not conceptually belong to an Entity nor to a Value Object you can put it in a service • Services are still a natural part of a model • Domain services should be distinguished from other services (application, infrastructural)
  • 29. Events • Event captures a change to the model so different model components can observe these changes and react accordingly
  • 30. Specification & Function • Entity.satisfies(Specification) • Entity.apply(Function) • Specification.satisfiedBy(Entity) • Function.applyTo(Entity)
  • 31. Strategic design • Abstract Core Domain & Generic Subdomains • Bounded Context & Context Map • Anti-Corruption Layer
  • 32. More reading • DDD community at domaindrivendesign.org • Books by: – Martin Fowler – Kent Beck – Alan Kay – Ward Cunningham

Notas do Editor

  1. adadada