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.