title: Where to put business logic in DDD
body: <p>I'm trying to figure out the best way to build an easily maintainable and testable architecture. Having gone through several projects, I've seen some pretty bad architectures and I want to avoid making future mistakes on my own projects.</p>
  
  <p>Let's say I'm building a fairly complex three layer application and I want to use DDD. My question is, where should I place my business logic? Some people say it should be placed in services (service layer) and that does make sense. Having a number of services which adhere to Single Responsibility Principle makes sense.</p>
  
  <p>However, some people said that this is an anti pattern and that business logic shouldn't be implemented in the service layer. Why is this?</p>
  
  <p>Let's say we have <code>IAuthenticationService</code> which has a method with <code>bool UsernameAvailable(string username)</code> signature. The method would implement all required logic to check whether the username is available or not.</p>
  
  <p>What is the problem here according to the "this is an antipattern" crowd?</p>