My company is trying to adopt DDD. It seems the DDD's guidance is to require the domain assembly to define all of its service interfaces and allow implementors to take a reference on the domain assembly and implement the service interfaces. Then using DI the domain will get the implementations. However, for cross cutting concerns, it seems irresponsible to require the domain assembly to re-define interfaces for things like logging, etc which are not the core business domain of that assembly. I've noted that a number of commercial components like Quartz.NET are using a standard, widely acceptable set of interfaces like Apache Commons to solve the cross cutting concerns in a framework friendly way. Is this consistent with DDD way or does one really have jump through hoops like AOP, and redefining the same interfaces for cross cutting concerns and then using an adapter pattern?
For reference:
From http://www.infoq.com/articles/ddd-in-practice
"These are reusable non-domain related concerns that typically tend to be scattered and duplicated all over the code including the domain layer. Embedding this logic in the domain objects leads to tangling and cluttering of the domain layer with non-domain related code."
From http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/
"Your cross-cutting concerns are someone else core domain"
It seems the DDD's guidance is to require the domain assembly
DDD doesn't require anything. A domain layer groups domain concepts and use cases. The abstractions defined at the Domain level are needed by the domain itself. And I mean needed by the domain use cases. Logging is an infrastructural (technical) aspect. Usually such abstractions are part of a common, shared layer/component and are usable by all the parts of the app.
The Domain doesn't care about this stuff and DDD shouldn't be considered a recipe, a 'how to'. It's a mindset where the design of the app revolves around business concepts and use cases, all other technical aspects are implementation details.
"Your cross-cutting concerns are someone else core domain"
This means the functionality that is simply a support system for you, it's the purpose (the domain) of other component.
I'd advise you too read way more about DDD and to try to grok the mindset and to employ a use-case approach for your app. Think of your app as a group of many specialized mini-apps, each with their very own concerns but which have to communicate with others. If you built things component by component, then you've understood DDD and incidentally you're also practicing Agile.