Leveraging more then DDD Lite in the startup project
Download as PPTX, PDF5 likes1,636 views
The document discusses developing a new application and considers adopting domain-driven design (DDD). It notes DDD could help by keeping the development on the right track, discovering concepts by challenging assumptions, and handling expected frequent changes. The document also discusses strategic design including working from use cases, modeling the domain, and iterative development. It introduces CQRS and considerations for using separate read/write data stores and event sourcing. Overall DDD is suggested to aid decoupling, maintainability and extensibility though mapping between domains remains a challenge.
Leveraging more then DDD Lite in the startup project
- 2. Points to consider • First rapide release • Should it be dirty but fast ? • Fear of overengeeniring / overdesign • Lack of explicit domain • Lack of domain expert
- 3. What we’re exactly doing ? Phase 1 • Gather user profiles • Offer configurable visual templates • Share on social networks Phase 2 • Web intelligence matching algo • Feedback collecting • Job offer recommendations
- 4. Going down the DDD path… • We want to avoid architecture 2011 effect
- 5. What DDD could bring us ? • Staying on the right track
- 7. What benefit DDD could bring us ? • Staying on the right track • Explicit behavior • Discovering concepts by challenging constantly what we know about the model • Application features are going to change often over the years (Vaughn Vernon IDDD book) • You don’t understand the domain because it’s new (Vaughn Vernon IDDD book)
- 8. Strategic design • Working on the use cases from screens • Making a model • Challenging your assumptions • Starting to define UL • Code / Refactor • Iterate over the points above
- 10. CQRS… what ? Idea behind • Separate write from reads Points to consider • Do I need a separate data store for r/w ? • Do I need ES ? • Do I need Event Store ? • Do I need Domain Events ? (more DDD part)
- 13. UI
- 14. UI
- 15. Domain
- 17. Validation
- 18. Validation Ex: 2
- 19. Validation Ex: 3
- 20. Domain
- 21. Breaking the rule • Rule of thumb : One aggregate state modification per transaction
- 23. UI
- 24. Infrastructure
- 25. Wrap up What I’ve achieved • Decoupling • Maintanibility • Extensibility What bothers me • Mapping (« at boundaries, application are not object oriented » Mark Seemann)
- 26. Proof