3.如何建模服务

1.什么样的服务是好服务

• 松耦合：能独立的修改及部署单个服务而不需要修改系统其他部分，一个松耦合服务应该尽可能少的知道与之协作的服务信息。
• 高内聚：把相关的行为聚集在一起，将不相关的行为放在别处，易于修改发布。

2.限界上下文
来自《领域驱动设计》的概念，任何一个给定的领域包含多个限界上下文，每个限界中的东西分为两个部分，一部分不需要与外部通信，另一部分则需要。每个衔接上下文都要明确接口，接口决定暴露哪些模型给其他的上下文。

• 共享的隐藏模型：两个独立的限界上下文有着共享模型，有时候同一名字在不同上下文中有着不同的含义。可以共享特点模型，不能共享内部表示。

• 模块和服务：发现领域内的衔接上下文，使用模块对其进行建模，同时使用共享和隐藏模型。模块边界可以成为微服务候选，微服务应该清晰的和限界上下文保持一致。

• 过早划分：过早将系统划分为微服务代价很高，很多时候，将一个已有的代码块划分为微服务比从头开始构建微服务简单。

3.业务功能

思考限界上下文时，应该从上下文能够提供的功能考虑，不应该从共享数据角度考虑。

4.逐步划分上下文

限界上下文划分可以从粗到细，可以使用嵌套或者完全分离方法，这却取决于组织结构，嵌套适合这些服务都是同一团队维护，分离则相反。嵌套的好处是使得架构成块，易于测试。

5.关于业务概念的沟通
修改系统目的是为了满足业务需求。对于某个功能的修改，应该局限于一个单独的微服务边界内。微服务间的通信形式也很重要。

6.技术边界
按照地理位置或者组织结构对单块系统划分是合理的，按照技术接缝对分为边界进行建模不总是错误，但一般不应该是考虑的首要方式。