PROSAGA码农传奇-SO业务编排-DDD - 具有多个“入口点”的应用程序服务位置

<div class =“post-text”itemprop =“text”>
  <BLOCKQUOTE>
    
      选项A：所有入口点DLL引用的专用应用程序服务项目（DLL）。
    
  </BLOCKQUOTE>
  
    这大致是我期望看到的。你有三个
    <a href="http://blog.ploeh.dk/2011/07/28/CompositionRoot/" rel="nofollow noreferrer">
      成分根
    </A>
     在这里，应该始终共享相同的模型（以确保所有路径强制执行当前的业务不变量）和相同的记录簿（如果他们不共享相同的记录簿，他们实际上不需要共享任何内容所有）。
  
  
    事实上，我强烈怀疑你可以将这些完全分开 - 在“微服务”中运行“模型”，并在上面部署三个接口，每个接口使用一个公共服务客户端DLL与该核心服务进行通信。
  
  
    例如，您可以查看
    <a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-1/" rel="nofollow noreferrer">
      洋葱建筑
    </A>
    。它与应用程序服务的单个dll的映像非常接近，每个组合都使用不同的接口来调整自己的API以适应模型的API。
  
  <BLOCKQUOTE>
    
      理论上，您必须为某些入口点部署具有过多功能的应用程序服务DLL。
    
  </BLOCKQUOTE>
  
    就是这样;那里有一个交易。我的猜测是，在大多数部署中，运行单个胖DLL比尝试部署具有相同模型的不同子集的多个jar更具成本效益。
  
  
    就个人而言，我首先从一个胖的微服务，一个设计良好的API，以及上面每个组成根中的胖客户端开始，然后如果权衡支持这种选择，必须用更薄，更专业的客户替换胖客户端。
  
  <BLOCKQUOTE>
    
      只是为了确保我理解你的一点。您是否建议我的域（您称之为“模型”）应该公开API，而我的不同入口点（您称之为“组合根”）应该调用此API？
    
  </BLOCKQUOTE>
  
    是的，这是对提案的公平描述，除非我想更清楚“应该公开API”部分。 API应该是明确的。也就是说，查看代码，您应该能够在代码中指向关注点分离的接缝
  
  <UL>
    <LI>
      
        这个
      
       部分是模特生活的地方
    </LI>
    <LI>
      
        那
      
       部分是专业化的地方
    </LI>
  </UL>
  
    您的选项B（如果您明确显示接缝）是在单个库中的这个想法。您的选项A就是这个想法，seam是两个库之间的接口（仍然在同一个进程中运行）。微服务就是这个想法，两个库在不同的进程中运行。
  
  
    您可以获得不同的权衡 - 例如，如果模型在专用的微服务中运行，那么（a）更改模型是“容易的”，因为只有一个权限可以换出，（b）您现在可以自由地实施任何可以与域服务交换消息的技术中的专用接口，（c）您也可以独立于扩展专业化的方式扩展模型。
  
  
    但是，您还会获得额外的复杂性，因为当客户端和服务器具有独立的部署周期时，您需要更多地考虑API的稳定性。
  
</DIV>