Search This Blog

Tuesday, November 5, 2013

Domain Services are part of the UL?

I finished Chapter 5 of Implementing Domain Driven Design. I wanted to poke my eyes out while he was describing how to handle an id, but I really enjoyed the part where he started talking about how we would model a User. I liked that he talked through how he made each design decision and what other alternatives were considered. It was a pretty simple example, but I think he was able to pack in a lot of good tips.

One thing I thought was interesting was how he decided to include his DomainService in the UL. Sometimes I see really generically named services called <AggregateName>Service where AggregateName could be any one of the Aggregate Roots in our domain. Usually those services are catch all bucket for a whole list of very loosely related methods. I think if the DomainService's name were part of the UL then people would probably name it something more specific. I also wonder if having a specific name would reduce the number of things the service does down to one thing. Hopefully having each service have one responsibility would make these classes a lot easier to understand and maintain.

At the end of the chapter the author starts talking about validation. I remember our team having the hardest time figuring out how to do validation that requires a UnitOfWork. He didn't really talk about that problem much other than mentioning you could use a DomainService or use events. Oh well maybe he talks more about it later in the book.