如何建模服务

什么样的服务是好服务

松耦合 和 高内聚

限界上下文

限界上下文 一个由显式边界限定的特定职责

共享的隐藏模型

对 于 MusicCorp 来说,财务部门和仓库就可以是两个独立的限界上下文。

有时候,同一个名字在不同的上下文中有着完全不同的含义。比如,退货表示的是客户退回的一些东西。在客户的上下文中,退货意味着打印运送标签、寄送包裹,然后等待退款。在仓库的上下文中,退货表示的是一个即将到来的包裹,而且这个包裹会重新人库。退货这个概念会与将要执行的任务相关,比如我们可能会发起一个重新入库的请求。这个退货的共享模型会在多个不同的进程中使用,并且在每个限界上下文中都会存在相应的实体 ,不过,这些实体仅仅是在每个上下文的内部表示而已。

模块和服务

模块边界就可以成为绝佳的微服务候选。一般来讲,微服务应该清晰地和限界上下文保持一致。

###　过早划分

过早将一个系统划分成为微服务的代价非常高,尤其是在面对新领域时。很多时候,将一个已有的代码库划分成微服务,要比从头开始构建微服务简单得多。

业务功能

当你在思考组织内的限界上下文时,不应该从共享数据的角度来考虑,而应该从这些上
文能够提供的功能来考虑。

避免基于CRUD ( create , read , update , delete ) 的服务。

逐步划分上下文

是否使用嵌套上下文，取决于两点：组织结构，测试

技术接缝

按照技术接缝对服务边界进行建模也并不总是错误的。比如,我见过当一个组织想要达到某个性能目标时,这种划分方式反而更合理。然而一般来讲,这不应该成为你考虑的首要方式。

推荐书籍：
领域驱动设计
实现领域驱动设计

转载请注明：转载自srzyhead的博客(https://srzyhead.github.io)

本文链接地址: 微服务设计 (3-如何建模服务)