Your SlideShare is downloading. ×
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Domain Driven Design   Mat Holroyd
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Domain Driven Design Mat Holroyd

496

Published on

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

No Downloads
Views
Total Views
496
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Domain Driven Design - take #2 Mat Holroyd
  • 2. The plan... Introduction ● The Domain Model ● Ubiquitous language ● Relevance of the model ● Putting the model to work ● Building blocks of the domain model ●
  • 3. Introduction What is domain driven design? ● Domain – Model – A collection of ideas ●
  • 4. The domain model Experts know about a domain ● The domain model is a 'rigorously organized ● and selective abstractions of that knowledge' Artificial – Distillation of knowledge – Domain experts and technical people both have to – learn new terminology
  • 5. The domain model - cont. Is the model a diagram(s)? ● Can any type of diagram be part of the model? ●
  • 6. Ubiquitous language Define one language ● One with the model ● Everyone uses it everywhere ● Design – Implementation, but also – Any communications (emails) – Discussions –
  • 7. Ubiquitous language - cont. Advantages? ● Who decides what term is correct? ● What's the cost of keeping documents up-to- ● date?
  • 8. Relevance of the model Model should form the basis of the design ● Implementation expresses the model ● Requires a suitable programming paradigm – Understanding come with doing ●
  • 9. Relevance of the model - cont. What happens if the model has little relevance ● to the code? What further understanding of the model does ● coding give a developer? Should abstractions be hidden from the user? ●
  • 10. Putting the model to work How should we transfer model to the code? ● Model-related objects are only a portion of the ● code Layered architecture is the way to go ● Domain layer is where model logic goes – No strict guidelines for other layers –
  • 11. Putting the model to work - cont. Keeping model logic in one place is good, but ● what can cause it to fragment? Disadvantages of layered architecture? ●
  • 12. Building blocks Entities ● Value objects ● Services ● Modules ●
  • 13. Building blocks - Entities Identity matters ● Attributes may be same as another ● Using reference alone may not be enough ● Identity can be formed from attributes ● Be careful! –
  • 14. Building blocks – Value Objects Identity does not matter ● 5, “the cat”, the color 'Red' ● Should be immutable ● Can be shared – Optimizations (maybe) – If mutable, cannot share ●
  • 15. Entities vs Value Objects Prefer value objects ● Easier to maintain – Easier to optimize – Can copy without concern –
  • 16. Building blocks – Services Action has no 'home' ● Contained to a layer ● Stateless ● Interface in terms of other domain object ●
  • 17. Building blocks – Modules Break up a system ● Can be explained with ubiquitous language ● High cohesion – Low coupling – Break up domain layer ● Not necessary to copy in other layers –
  • 18. Building blocks - Questions Entities and value objects – are they for any ● layer? What about supporting code, such as lists. Do ● they fit under the title of entities or value objects?
  • 19. My thoughts Side-effect free functions, value ● objects...sounds like functional programming Concepts help explain advantages and ● disadvantages of Ruby-on-Rails and Access Large parts of infrastructure is written already – Not using single model explains why 'those ● bloody coders did not implement it as they are supposed to!'

×