标签：团队管理 信息 模型 height 第三章 功能 耦合 共享数据 高内聚
什么好的服务？
松耦合
一个松耦合的服务应该尽可能的少知道与之协作的那些服务的信息。
如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一个服务。
使用微服务的特定就是可以独立的修改和部署单个服务而不需要修改系统的其他部分。
高内聚
把相关的行为聚集在一起，把不相关的行为放在别处。
因为如果改变某个行为的话，最好能够只在一个地方进行修改，然后就可以尽快的发布。减少部署多个服务的风险。
限界上下文
一个由显式边界限定的特定职责。
共享的隐藏模型
例如财务与仓库两个独立的限界上下文，他们都有自己的对外接口；财务不需要知道仓库的内部细节，但是财务需要知道仓库的库存水平用于更新账户，为这个这种需求，可以再财务与仓库之间创建一个库存项的共享模型。使用共享牟模型可以防止紧耦合的风险。
模块和服务
边界内部是相关性比较高的业务功能，从而得到高内聚，这些限界上线文可以很好地形成组合边界。
模块边界可以称为绝佳的微服务候选，一般来说，微服务应该清晰地和限界上下文保持一致。
过早划分
过早的划分微服务会是有问题的，会导致在早期的开发过程中很多的跨服务修改，而这些修改的代价相当高。
将一个已有的代码库划分为微服务要比从头开始构建微服务简单的多。
业务功能
当你在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而是应该从这些上下文能够提供的功能来考虑。即首先考虑这些上下文时用来做什么的，在考虑它需要什么样的数据。
建模服务时，应该讲这些功能作为关键操作提供为其协作者（其他服务）。
逐步划分上下文
可以先识别粗粒度的限界上下文，而这些限界上下文可能又包含一些嵌套的限界上下文。
需要选择是使用嵌套的方式还是完全分离的方法来定义限界上下文。
倾向于使用嵌套方法的原因是它可以使得架构更成块从而更好的测试。
使用嵌套方法：如果所有服务都是由一个团队管理的，那么嵌套结构会更合理，其原因在于组织架结构和软件架构会相互影响。
第三章：如何建模服务
标签：团队管理 信息 模型 height 第三章 功能 耦合 共享数据 高内聚
原文地址：https://www.cnblogs.com/use-D/p/9874050.html
