Project Silk subjective review part 2 no DDD, no CQRS and mighty handlers of doom

This is part 2 of my review.

In docs there is no mention about DDD or CQRS.  That’s great because app seems to be fairly simple and CRUD should suffice. But when you look at folder structure this pops up:

Hmmm so there is a domain, and a model (separate ? ) and there are some services…

The domain

Going into MileageStats.Model and looking through the classes  – they look very anemic. Looking through how the classes are used reveals it is used as a domain model.

Now MileageStats.Domain even more interesting:

There is another model:

After looking at how it is used – it’s a Read Model! So what the heck is it doing in Domain? It should be placed in a separate project.

Mighty handlers of doom

Let’s go back to MileaseStats.Domain.Handlers. Name implies there is some kind of messaging(commands/events or cqrs even?) right? Let’s have a look at AddFillupToVehicle:

Hmm, these handlers have a lot of business logic, but according to Greg Young :

The responsibility of these commandhandlers is to execute the appropriate behavior on the domain.

The command handlershould not be doing any domain logic itself. If there is a need for this than that logic should be moved into a service of its own.

Oh and handlers are used to get domain data from repository:

And also to do validation:

And to get read model data:

Now that is a lot of responsibility for handlers….

Using handlers

Duh, creating handlers a in controller action, so there is no bus or any other messaging infrastructure.

That “Using” part is also interesting but that’s a topic for a next post.

Tagged , ,

2 thoughts on “Project Silk subjective review part 2 no DDD, no CQRS and mighty handlers of doom

  1. aspcoder says:

    DO u have any recommendation for a CQRS flavored architecture.

  2. hmm, there are some nice examples on github by Szymon Pobiega

Leave a Reply

Your email address will not be published. Required fields are marked *