建模:肯定服务的边界——《微服务设计》读书笔记
什么样的服务才是好的服务?html
高内聚、松耦合的服务才是好的服务。简而言之，就是把相关性强的放在一块儿，相关性不强的分开，物以类聚，人以群分，服务的划分也是这样。这就须要肯定什么要放在一块儿，什么是要分开的，这个寻找的过程就是肯定服务边界的过程。微信
限界上下文架构
限界上下文肯定了这个边界内它所承担的职责。微服务
Evans在《领域驱动设计》中做喻：细胞之因此会存在，是由于细胞膜定义了什么在细胞内，什么在细胞外，而且肯定了什么物质能够经过细胞。这是限界上下文的绝比如喻。性能
任何一个给定的领域都包含多个限界上下文。限界上下文中包含了一些内容（或者叫模型），它们的相关性较高，一部分须要与外部通讯，一部分不须要与外部通讯，每一个限界上下文都有明确的接口，该接口决定了它会暴露哪些模型给其余的上下文。外部想与限界上下文通讯，须要使用模型和它的显式限界（接口）进行通讯。这样作能够获得高内聚，从而很好地造成组合限界。spa
限界与限界之间，也会存在共享模型，以下所示，仓库和财务都须要库存信息，但不能把仓库全部的库存信息都给财务，由于有些信息对于财务是并无用的，同时也不能让财务伸到仓库内部去取数据，这样有可能会破坏限界上下文的完整性，所以，咱们提供了一个共享模型——库存项。设计
这些模块限界就能够成为绝佳的微服务候选，通常来讲，微服务应清晰地和限界上下文保持一致。htm
如何肯定限界上下文blog
1.推荐使用领域来表分解限界上下文接口
若是把系统分解成为限界上下文来表示领域的话，那么对于某个功能所作的修改，就更倾向于在一个单独的微服务限界以内。另外，服务之间应该共享相同的术语，也应该反映到服务的接口上。
2.应从限界上下文提供的功能来考虑，而不是数据
只考虑数据和模型，不考虑上下文的功能，很容易致使“贫血”，因此要先问“这个上下文是作什么用的“，再考虑它”须要什么样的数据“。
3.不要过早划分上下文
对于一个新系统而言，能够先使用一段时间的单块系统，由于若是服务之间的限界搞错了，后面修复的代价就会很大，因此最好可以等到系统稳定下来以后，再肯定把哪些东西做为一个服务划分出去。
4.不要排斥嵌套上下文
一开始，你会识别一些粗粒度的限界上下文，而这些限界上下文可能又包含一些嵌套的限界上下文。以下所示：使用这些嵌套的上下文不直接对外可见，对于外界来讲，它们用的仍是仓库的功能，但发出的请求其实被透明地映射到了两个或更多有服务上。
固然，根据每一个团队的状况不一样，咱们也能够将仓库的内的上下文再隔离出来，以下所示：
5.谨慎根据技术边界来肯定上下文
通常而言，咱们建议按照业务的垂直划分来创建上下文，而不是按照技术的分层来肯定上下文，好比，你若是将DAO、BLL、UI层分红3个不一样的服务，那么当你须要变动业务的时候，你须要频繁地同时修改两个服务，这样显然是不合理的。但也不是说这样划分老是不合理，若是一个组织想达到某个性能目标，这样划分反而更合理。
参考
《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）
相关文章：
原文地址：http://www.cnblogs.com/gudi/p/6613989.html
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注