title: ASP.NET MVC Enterprise DDD Architecture and WCF layer
body: <p>I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:</p>
  
  <ul>
  <li>MyApp.Core - the app core, contains the domain models etc.</li>
  <li>MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.</li>
  <li>MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)</li>
  <li>MyApp.Web.Infrastructure - web implementation</li>
  <li>MyApp.Web.UI - ASP.NET MVC standard application.</li>
  </ul>
  
  <p>This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.</p>
  
  <p>When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.</p>
  
  <p>I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
  - Why should someone not just use the Services in the controllers and instead use an API?
  - In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
  - If I should use WCF, or ASP.NET WebAPI?</p>
  
  <p>Thanks for any feedback and help!</p>