title: Domain Driven Design and cross cutting concern interface definition
body: <p>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?</p>
  
  <p>For reference:</p>
  
  <p>From <a href="http://www.infoq.com/articles/ddd-in-practice" rel="nofollow">http://www.infoq.com/articles/ddd-in-practice</a></p>
  
  <p>"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."</p>
  
  <p>From <a href="http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/" rel="nofollow">http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/</a></p>
  
  <p>"Your cross-cutting concerns are someone else core domain"</p>