title: Open Host Service VS Application layer
body: <p><strong>OHS</strong> ... Open Host Service <br />
  <strong>AL</strong>  ... Application Layer <br />
  <strong>ACL</strong> ... AntiCorruption Layer <br />
  <strong>BC</strong>  ... Bounded Context</p>
  
  <p><strong>1.</strong></p>
  
  <p>Here I'll use the term <strong>unidirectional</strong> when <strong>our</strong> <em>OHS's public interface</em> can only be used by <em>external</em> BCs to call <strong>our</strong> system, but it can't be used by <strong>our</strong> BCs to call <em>external</em> systems</p>
  
  <p>Similarly, I'll use the term <strong>bidirectional</strong> when <strong>our</strong> <em>OHS's public interface</em> can be used by <em>external</em> BCs to call <strong>our</strong> system, but it can also be used by <strong>our</strong> BCs to call <em>external</em> systems</p>
  
  <p>a) Is <strong>OHS</strong> <em>unidirectional</em> or can it also be <em>bidirectional</em>? I'd say it can only be <em>unidirectional</em>?</p>
  
  <p>b) Similarly, is <strong>AL</strong> <em>unidirectional</em> or can it also be <em>bidirectional</em>? I'd say it can only be <em>unidirectional</em>?</p>
  
  <p><strong>2.</strong> I assume <strong>OHS</strong> doesn't replace <strong>AL</strong>, but instead sits on top of <em>Application services/AL</em>?</p>
  
  <p><strong>3.</strong></p>
  
  <p>a) Should <strong>OHS</strong> also be used for communication between BCs that are part of the same application or should it <strong>only</strong> be used for communication with <em>external</em> BCs? Whatever the answer, please elaborate your reasoning?</p>
  
  <p>b) Assuming BCs communicating with each other are part of the same application and assuming we don't use <strong>OHS</strong> - should these BCs communicate with each other <em>directly</em> ( ie. BC would call <strong>ACL</strong>, which in turn would make a direct call to BC ) or via <strong>AL</strong> ( ie. BC would call <strong>ACL</strong>, which would call <strong>AL</strong>, which then would make a direct call to BC )? </p>
  
  <p>I'd argue that these BCs should communicate <em>directly</em> and not via <strong>AL</strong>, since it may bloat <strong>AL's</strong> interface and may also expose <em>inner</em> functionality to <em>external</em> systems?</p>
  
  <p><strong>4.</strong></p>
  
  <p>Eric Evan's DDD book, pg. 375:</p>
  
  <blockquote>
    <p>Open Host Service uses a standardized protocol for multiparty
    integration. It employs a model of the domain for interchange between
    systems, even though that model may not be used internally by those
    systems.</p>
  </blockquote>
  
  <p>a) I assume <strong>our</strong> OHS should use <strong>our</strong> <em>application's</em> domain model only as the basis for <em>its own model</em>? In other words, <strong>OHS</strong> shouldn't use <em>application's</em> domain model, but should instead just base its <em>very own model</em> on it?</p>
  
  <p>b) Since <strong>our</strong> OHS has it's <em>very own model</em> ( which is usually based on <em>Core Domain</em>, whatever that may be ), I assume that we should also define a <em>translation/anticorruption layer</em> sitting between <strong>OHS</strong> and the rest of our application?</p>
  
  <p>c) Are <em>arguments</em> and <em>return values</em> of <em>Application services</em> defined in terms of <em>application's</em> domain model?</p>
  
  <p><strong>5.</strong></p>
  
  <p>Does BC always use <em>Infrastructure services</em> to call another BC ( of course if BC is using <strong>ACL</strong>, then BC would call <strong>ACL</strong>, which in turn would call <em>Infrastructure layer</em>, which would then call the other BC ), regardless if that other BC is <em>external</em> or part of the same application? </p>
  
  <p>thanks</p>
  
  <p><strong>EULERFX:</strong></p>
  
  <p><strong>1.</strong> </p>
  
  <blockquote>
    <p>1b) An ACL is bidirectional in that data flows in either direction -
    either when you're sending a message to external service or
    interpreting a message received from said service.</p>
  </blockquote>
  
  <p>a) By "<em>or interpreting a message received from said service</em>" you mean only that <strong>our</strong> ACL <strong>can</strong> receive a <em>reply</em> ( ie. <em>return value</em> ) from the <em>called external</em> BC  or do you also mean that the <em>same</em> <strong>ACL</strong> which sends messages ( on behalf of <strong>our</strong> BCs ) can also interpret the messages when <em>external</em> BCs call <strong>our</strong> BCs?</p>
  
  <p>b) If the <strong>former</strong>, then isn't in that sense <strong>OHS</strong> also <em>bidirectional</em> since <strong>OHS</strong> <em>services</em> called by <em>external</em> systems can also send <em>reply</em> ( ie. <em>return value</em> ) back to these <em>external</em> systems? If the <strong>latter</strong>, in <strong>4b)</strong> you said <strong>OHS</strong> itself also acts as a <em>translator</em>, which suggests that <em>ACL</em> used by <strong>our</strong> BC for calling <em>external</em> systems won't also be used when <em>external</em> systems call our BC, which would imply that <strong>ACL</strong> can't be <em>bidirectional</em>?</p>
  
  <p><strong>3.</strong></p>
  
  <blockquote>
    <blockquote>
      <p>3b) Assuming BCs communicating with each other are part of the same
      application and assuming we don't use OHS - should these BCs
      communicate with each other directly ( ie. BC would call ACL, which in
      turn would make a direct call to BC ) or via AL ( ie. BC would call
      ACL, which would call AL, which then would make a direct call to BC )?</p>
    </blockquote>
    
    <p>If not using OHS, call the application service of the other BC.</p>
  </blockquote>
  
  <p>a) So you're saying that BC should call <strong>ACL</strong>, which would call <strong>AL</strong>, which then would make a direct call to the other BC? </p>
  
  <p>b) Do BCs within the <em>same</em> application <em>share</em> the same <strong>AL</strong>? </p>
  
  <p>c) If <em>internal</em> BCs do share the same <strong>AL</strong>, doesn't this mean that we may be forced to define some  <em>Application services</em> whose only purpose is to enable <em>internal</em> BCs  to communicate with each other ( thus <em>external clients</em> are not meant to call these particular <em>Application services</em> ). As such, don't these <em>Application services</em> expose inner functionality to <em>external clients</em>? </p>
  
  <p><strong>Clarification:</strong> I know that <em>external clients</em> can only directly call our <em>Application services</em> if they have a reference to <em>dll</em> containing our <em>Application services</em>, but if some <em>clients</em> do have a reference to such <em>dll</em>, then there's a possibility they may call <em>Application services</em> intended to be used only by <em>internal</em> BCs calling each other?</p>
  
  <p><strong>4.</strong></p>
  
  <p>b) </p>
  
  <blockquote>
    <blockquote>
      <p>I assume that we should also define a translation/anticorruption layer
      sitting between OHS and the rest of our application?</p>
    </blockquote>
    
    <p>In effect, the OHS will be that translation layer. It will delegate
    all behavior to application service, in the process adapting to the
    specific technology used to implement OHS.</p>
  </blockquote>
  
  <p>According to Evans, <strong>OHS</strong> should use the underlying <em>domain model</em> only as the basis for its own model, meaning the <em>two models</em> should be separate "instances".</p>
  
  <p><em>Domain models</em> should be completely oblivious to anything except the <em>domain</em> they model. Don't same rules also apply to <strong>OHS</strong> <em>model</em>? In other words, shouldn't <strong>OHS</strong> <em>model</em> be unaware of other layers and domains and as such it shouldn't be bothered with translating messages from its <em>own model</em> into the <em>domain model</em> encapsulated by the underlying <strong>AL</strong>?</p>
  
  <p>c)  </p>
  
  <blockquote>
    <blockquote>
      <p>Are arguments and return values of Application services defined in
      terms of application's domain model?</p>
    </blockquote>
    
    <p>define interface in terms of DTOs</p>
  </blockquote>
  
  <p>Assuming the <em>interfaces of Application Services</em> are defined in terms of DTOs: <strong>OHS</strong> is defined in terms of <strong>OHS</strong> <em>model</em> and the <em>Application Services</em> encapsulate the <em>domain model</em>, but what model defines these DTOs? In other words, are these DTOs part of <strong>OHS</strong> <em>model</em>, part of <em>domain model</em> encapsulated by <strong>AL</strong> or... ?</p>
  
  <p><strong>5.</strong> </p>
  
  <blockquote>
    <blockquote>
      <p>Does BC always use Infrastructure services to call another BC ( of
      course if BC is using ACL, then BC would call ACL, which in turn would
      call Infrastructure layer, which would then call the other BC ),
      regardless if that other BC is external or part of the same
      application?</p>
    </blockquote>
    
    <p>It can be said that regardless of whether the called BC is internal or
    external, you still employ an ACL to one degree or another.</p>
  </blockquote>
  
  <p>a) Shouldn't <strong>ACL</strong> be applied only when there's a danger of the <em>outside model</em> leaking into <em>our model</em>? </p>
  
  <p>b) Since <em>internal</em> BCs ( BCs within the same application ) should talk to each other via <strong>AL</strong>, I assume you'd have these BCs call <strong>AL</strong> via <em>Infrastructure layer</em>, since <em>Domain layer</em> shouldn't have any dependencies on <em>upper layers</em> ( ie. <strong>AL</strong> )?</p>
  
  <p>c) So you disagree with @<strong>mrhobo</strong>, which states that <em>internal</em> BCs should communicate with each other <strong>directly</strong> ( if BC is using <strong>ACL</strong>, then BC would <strong>directly</strong> call <strong>ACL</strong>, which in turn would call the other BC ) and not via <strong>AL</strong>? Why?</p>
  
  <p><strong>EULERFX, second update:</strong></p>
  
  <p>1.</p>
  
  <p>b) </p>
  
  <blockquote>
    <blockquote>
      <p>If the latter, in 4b) you said OHS itself also acts as a translator,
      which suggests that ACL used by our BC for calling external systems
      won't also be used when external systems call our BC, which would
      imply that ACL can't be bidirectional?</p>
    </blockquote>
    
    <p>The translation performed by the OHS, while similar to an ACL is
    different in nature because it is of a technical character.</p>
  </blockquote>
  
  <p>So what did Evans mean by ( pg. 368 ) <strong>"ACL can be bidirectional"</strong> , since if communication is implemented as you suggest, then <strong>ACL</strong> can never be <em>bidirectional</em> ( while <strong>ACL1</strong> used by  <strong>BC1</strong> can receive a <em>reply</em> from <strong>BC2</strong>, <strong>ACL1</strong> will never be used when <strong>BC2</strong> calls <strong>BC1</strong>, even if both <strong>BC1</strong> and <strong>BC2</strong> are <em>internal</em> – note that I'm aware that <strong>BC2</strong> will use its own <strong>ACL</strong>, I'm just pointing out that <em>Evans</em> talks about <em>bidirectional</em> <strong>ACLs</strong>. In other words, he's implying that when <strong>BC2</strong> calls <strong>BC1</strong>, this call would be received by <strong>ACL1</strong> )?</p>
  
  <p><strong>3.</strong></p>
  
  <blockquote>
    <blockquote>
      <p>c) If internal BCs do share the same AL, doesn't this mean that we may
      be forced to define some Application services whose only purpose is to
      enable internal BCs to communicate with each other ( thus external
      clientsare not meant to call these particular Application services ).
      As such, don't these Application services expose inner functionality
      to external clients?</p>
    </blockquote>
    
    <p>As above, BCs should share application services even if they internal.
    That doesn't make much sense.</p>
  </blockquote>
  
  <p>a) I assume it's a typo and you meant <em>shouldn't</em> instead of <em>should</em>?</p>
  
  <p>b) <em>Internal</em> BC also don't share <strong>OHS</strong>? </p>
  
  <p>c) If <em>internal</em> BCs communicated with each other via <strong>OHS</strong>, wouldn't we face same problems as when these BCs communicate via <strong>AL</strong> ( ie. we may be forced to define some <strong>OHS</strong> <em>services</em> whose only purpose is to enable <em>internal</em> BCs to communicate with each other, and as such these <strong>OHC</strong> <em>services</em> may expose <em>inner</em> functionality to <em>external</em> clients )? </p>
  
  <p><strong>5.</strong></p>
  
  <p>a)</p>
  
  <blockquote>
    <blockquote>
      <p>Shouldn't ACL be applied only when there's a danger of the outside
      model leaking into our model?</p>
    </blockquote>
    
    <p>Yes, but that will always be the case if you're calling some
    external BC. If the BCs are locally owned then you can have some
    mutual agreement on model (shared kernel), but it is still often
    easier to decoupled them.</p>
  </blockquote>
  
  <p>I thought even when <em>decoupled</em>, we can still have a simple <em>translation layer</em> ( instead of full blown <strong>ACL</strong> ) if the <em>public interface</em> between two BCs is <em>simple</em> enough ( at least that's how I understood Evans )?</p>
  
  <p><strong>MRHOBO</strong></p>
  
  <p>3.</p>
  
  <p>b) </p>
  
  <blockquote>
    <blockquote>
      <p>Assuming BCs communicating with each other are part of the same
      application and assuming we don't use OHS - should these BCs
      communicate with each other directly ( ie. BC would call ACL, which in
      turn would make a direct call to BC ) or via AL ( ie. BC would call
      ACL, which would call AL, which then would make a direct call to BC )?</p>
    </blockquote>
    
    <p>The AL is meant to separate the domain from it's users and ways of
    usage. Different BC's living within the same application should not
    communicate through such layers, but should instead be part of the
    same domain layer.</p>
  </blockquote>
  
  <p>So you disagree with @<strong>eulerfx</strong> about <em>internal</em> BCs calling each other through <strong>AL</strong>? Why?</p>
  
  <p>2) </p>
  
  <blockquote>
    <blockquote>
      <p>I assume OHS doesn't replace AL, but instead sits on top of
      Application services/AL?</p>
    </blockquote>
    
    <p>It could sit on top of an AL, but could also sit directly on top of
    the BC. An AL and a OHS are very similar. If all usage of the BC
    depends on the OHS, in my opinion, there is little need to create an
    in between AL.</p>
  </blockquote>
  
  <p>Could you clarify in what situations all usage of BC would depend only on <strong>OHS</strong> and when would it also depend on <strong>AL</strong>?</p>
  
  <p>4.</p>
  
  <p>b) </p>
  
  <blockquote>
    <blockquote>
      <p>Since our OHS has it's very own model ( which is usually based on Core
      Domain, whatever that may be ), I assume that we should also define a
      translation/anticorruption layer sitting between OHS and the rest of
      our application?</p>
    </blockquote>
    
    <p>You will need adaptors to translate between the domain model and the
    interaction model, yes. The ACL, however, is meant to integrate two
    BC's in such a way that the BC that uses the ACL is unaware of the
    existence of another BC. This comes in handy for a client using an
    OHS, but should not go in between the OHS and the BC on the server
    side.</p>
  </blockquote>
  
  <p>In other words, the <em>translator</em> between <strong>OHS</strong> and <strong>AL</strong> shouldn't be <strong>ACL</strong>, but instead just a "regular" <em>translator</em>?</p>