CODEWITHSUNDEEP
architecturedomain-driven-designcqrs
Denis Pshenov
Denis Pshenov

Reputation: 11327

In context of CQRS and DDD how would you handle slightly varying use cases?

I could have a command for each variation or I could have one command and handle variations within it.

To illustrate, I have three use cases (or more), "CommentOnPhoto", "CommentOnWall", "CommentOnArticle". All of them internally use the same commenting system. The difference between three is:

If going the route of one command for each variation then should each command inherit from some base CommentOnSomething command since they are all very similar?

If going the route of one mother command for all use cases then we will have to make use of Service Locator to pull needed Policies and Repositories on demand (we don't want to inject 10+ dependencies for each use case only to use one). Is this acceptable if we make use of abstract factories and such to hide away service locator use? Meaning we have CommentPolicyFactory and CommentableFactory which use Service Locator internally to deliver the right policy and the right aggregate.

Upvotes: 2

Views: 351

Answers (1)

g45rg34d
g45rg34d

Reputation: 9660

One command per variation.

I would first focus on creating a very generic "commenting" component (as its own project, decoupled from your core domain). Once you have it, then your commands CommentOnPhoto, CommentsOnWall and others will become very simple with just a few lines of code.

Upvotes: 2

Related Questions