Hi,
Sorry for my late response. We've been quite busy getting the book ready for print.
First what I am missing is what happened now to the repository interfaces and implementations. Should these also change to SRP.
That's actually a hard question to answer, because it will typically depend a lot on the system you are building. What I found, however, is that from the query side of things, query handlers (e.g. `IQueryHandler<TQuery, TResult>`) effectively replace the use of repositories. If we look at this from the point of view of an MVC Controller, for instance, you won't find any GET action to use a repository abstraction, they will solely use a query handler.
From a domain's perspective, things might be different though. The logic inside a command handler (which will typically contain domain logic), might still use repository interfaces, although you should definitely be conscious of any maintainability issues that might be caused by wide interfaces, which is something that might happen when you start applying cross-cutting concerns around those abstractions.
In the Listing in chapter 10 and the decorators. Like auditing security, there is no repository injected instead the CommerceContext is directly injected. This confused me because now the domain layer would have again a dependency to the data access layer.
One of the shown command handlers in chapter 10 accidentally depended on CommerceContext. This is an error and will be fixed before we go to print. This is a DIP violation.
Having a decorator depend on the CommerceContext, however, will not be a problem when the decorator is part of the Composition Root. The Composition Root depends on all other modules in the system anyway. If, however, you need to place that decorator in the Domain Layer, you will have to refactor the dependency on CommerceContext, because otherwise the Domain Layer would require a dependency on the Data Access Layer.
I for my part think that service and repository interface should also be not in the same assembly, am I right?
Since it is the Domain layer that uses the repository interfaces, the DIP states that it should own that interface. This typically means placing the interface inside the same assembly. It is possible to place the repository interfaces in a different assembly, but there should be a benefit of doing so. For instance to be able to deploy the Domain Layer and Data Access Layer separately. Deploying the DAL without the DL, however, typically makes no sense, because the DL is the heart of the application, and it is always needed.
The last problem I have is with implementation of POCO's, which depends on each other (e.g. order and items). What for me is important is especially an approach with Transaction in mind. So, when something went wrong there is a rollback for the order and all its items. Next to find and inform the right warehouse, inform the billings system when products are ordered, there has to already a change in the disposition within the scope of the transaction.
For any distributed system, transactional consistency is an illusion. Any time your application needs to communicate with a different system (e.g. billing, warehouse, etc.) you can't really have those systems perform that operation in a single transaction. Doing so would cause a distributed transaction, and this has many negative consequences.
The solution to this problem is Eventual Consistency, which is what chapter 6 is hinting at with its use of Domain Events. When we use Eventual Consistency rather than distributed transactions, any single application in the distributed system will ensure that its data is stored in such way that it won't lose any data, preferably with transactions. For instance, both the publication of the Domain events and the changes to its internal database will be transactional. So what this means is that once the OrderApproved Domain Event is stored in the durable queue (which could be a database table), we will not yet have notified Accounting and Billing, but those systems will *eventually* be notified. When the notification succeeds, the applications will be consistent again.
This whole concept of Eventual Consistency is very important when you start working with either distributed systems or when applying Domain Events. A discussion about this, however, was outside the scope of this book.
I hope this makes sense.