title: Domain driven design - database transaction management
body: <p>I'm trying to implement Domain Driven Design with Unit Of Pattern in my app using ASP.Net WebApi.</p>
  
  <p><strong>1) Where should I start/commit transactions</strong> (API controller, application layer/service, DAL, domain layer/service)?</p>
  
  <p><strong>2) What is the best way to manage transactions in complex application with a lot of bussines rules</strong> (AOP, explicit call or somehow else)?</p>
  
  <p><strong>3) What is the best way to reuse one piece of code with transaction in more bigger transaction?</strong> 
  i.g. I have independent use case - close invoice - which contains the transaction already. Also this code contains some non domain code like logging, statistics counting and etc.
  And I want to reuse this code in more complex use case - paying invoice, deduction of commissions and closing invoice.</p>
  
  <p><strong>3.1)</strong> How you deal with an inner transaction problem (popular databases don't support it)?</p>
  
  <p><strong>3.2)</strong> What should layer be responsible for this?</p>
  
  <p>I know answers may depend on a particular project. But it would be great to consider any workable in real projects techniques</p>