Points to consider• First rapide release• Should it be dirty but fast ?• Fear of overengeeniring / overdesign• Lack of exp...
What we’re exactly doing ?Phase 1• Gather user profiles• Offer configurable visual templates• Share on social networksPhas...
Going down the DDD path…• We want to avoidarchitecture 2011effect
What DDD could bring us ?• Staying on the right track
What benefit DDD could bring us ?• Staying on the right track• Explicit behavior• Discovering concepts by challengingconst...
Strategic design• Working on the use cases from screens• Making a model• Challenging your assumptions• Starting to define ...
CQRS… what ?Idea behind• Separate write from readsPoints to consider• Do I need a separate data store for r/w ?• Do I need...
UI
UI
Domain
Infrastructure CommandProc
Validation
Validation Ex: 2
Validation Ex: 3
Domain
Breaking the rule• Rule of thumb : One aggregate statemodification per transaction
UI
Infrastructure
Wrap upWhat I’ve achieved• Decoupling• Maintanibility• ExtensibilityWhat bothers me• Mapping (« at boundaries, application...
Proof
Leveraging more then DDD Lite in the startup project
Leveraging more then DDD Lite in the startup project
Leveraging more then DDD Lite in the startup project
Leveraging more then DDD Lite in the startup project
Leveraging more then DDD Lite in the startup project
Leveraging more then DDD Lite in the startup project
Prochain SlideShare
Chargement dans…5
×

Leveraging more then DDD Lite in the startup project

1 007 vues

Publié le

Short presentation about how Domain Driven Design help me with my startup project. A lightweight CQRS approach was used (commands separated from queries without other ceremony).

Publié dans : Technologie, Business

Leveraging more then DDD Lite in the startup project

  1. 1. Points to consider• First rapide release• Should it be dirty but fast ?• Fear of overengeeniring / overdesign• Lack of explicit domain• Lack of domain expert
  2. 2. What we’re exactly doing ?Phase 1• Gather user profiles• Offer configurable visual templates• Share on social networksPhase 2• Web intelligence matching algo• Feedback collecting• Job offer recommendations
  3. 3. Going down the DDD path…• We want to avoidarchitecture 2011effect
  4. 4. What DDD could bring us ?• Staying on the right track
  5. 5. What benefit DDD could bring us ?• Staying on the right track• Explicit behavior• Discovering concepts by challengingconstantly what we know about the model• Application features are going to change oftenover the years (Vaughn Vernon IDDD book)• You don’t understand the domain because it’snew (Vaughn Vernon IDDD book)
  6. 6. 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
  7. 7. CQRS… what ?Idea behind• Separate write from readsPoints 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)
  8. 8. UI
  9. 9. UI
  10. 10. Domain
  11. 11. Infrastructure CommandProc
  12. 12. Validation
  13. 13. Validation Ex: 2
  14. 14. Validation Ex: 3
  15. 15. Domain
  16. 16. Breaking the rule• Rule of thumb : One aggregate statemodification per transaction
  17. 17. UI
  18. 18. Infrastructure
  19. 19. Wrap upWhat I’ve achieved• Decoupling• Maintanibility• ExtensibilityWhat bothers me• Mapping (« at boundaries, application are notobject oriented » Mark Seemann)
  20. 20. Proof

×