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