title: How to expose domain and repository layer as a service?
body: <p>I have the following layers currently in my application:</p>
  
  <ol>
  <li>API</li>
  <li>AppService Layer</li>
  <li>Domain Model</li>
  <li>Repository</li>
  </ol>
  
  <p>The lower (2) layers (domain and repository) offer almost total reuse across business needs so I thought of exposing at least my domain model as a service, possibly a WCF service. Basically the domain entity data, behavior, and persistance are reusable and I need a way to centrally expose this. </p>
  
  <p>I have read the following (<a href="https://stackoverflow.com/questions/1468573/sharing-domain-model-with-wcf-service">Sharing domain model with WCF service</a>) and ones similar that indicate for good reason why <em>not</em> to expose domain entities directly via WCF. Most of the examples indicate to create data contracts to expose domain data and then have mapping mechnisms to map between the domain and DTO (Data Contract) data. So far so good.</p>
  
  <p>If I have a method in my domain layer like below, how do I expose it via the new WCF service? I thought I would only expose DTOs and therefore how do I also expose the shared/common domain behavior I want to reuse across processes?</p>
  
  <pre><code>public int ProcessSomeRule(string param1, string param2)
  </code></pre>
  
  <p>If the answer is to create a method on the WCF service that acts as a proxy still not exposing the <code>ProcessSomeRule</code> method directly, I'm cool with that but that spawns another question. The purpose of this abstraction and creating a method on the WCF service named for example <code>ProcessSomeRuleWCF(string,string)</code> that just turns around internally and calls the domain method seems to still be coupled and not offer a pure abstraction. It will still be sensitive to signature changes.</p>
  
  <p>I read that by not exposing the methods directly, we can make changes internally without having to modify the contract interface. OK, this sounds great by definition, but if my internal method needs an <em>additional</em> parameter and now has the signature `ProcessSomeRule(string, string, string), guess what? My contract interface method will now break because it's missing the 3rd parameter, so my interface <em>has</em> to change. Not sure how to do this and still make the abstraction worthwhile?</p>
  
  <p>My repository in the <em>same</em> manner is generic and can be used across processes and I want to reuse this layer too. Currently my repository (UoW) Interface is injected into my AppService layer, so I have no idea how this would work if Repository layer was a WCF service.</p>
  
  <p><strong>Question:</strong> How do I expose the shared behavior of the domain and repository layers and what would the names of these new layers be called? Is the new layer exposing the domain named 'Domain Service' and sit between 'AppService' and 'DomainModel'?</p>
  
  <p>Lastly, if I'm on the wrong path with any of this feel free to guide me back. Thanks!</p>