Points to consider

• First rapide release• Should it be dirty but fast ?• Fear of overengeeniring / overdesign• Lack of explicit domain• Lack of domain expert

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

Going down the DDD path…

• We want to avoid architecture 2011 effect

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 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)

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

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)

UI

UI

Domain

Infrastructure CommandProc

Validation

Validation Ex: 2

Validation Ex: 3

Domain

Breaking the rule

• Rule of thumb : One aggregate state modification per transaction

UI

Infrastructure

Wrap up

What I’ve achieved• Decoupling• Maintanibility• ExtensibilityWhat bothers me• Mapping (« at boundaries, application are not

object oriented » Mark Seemann)

Proof