如何建模服务
1、什么样的服务是好服务？
（1）、松耦合
使用微服务，能够独立修改及部署单个服务而不需要修改系统的其他部分，这就是实现松耦合，这非常重要。一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。
（2）、高内聚
把相关的行为聚集在一起，把不相关的行为放在别处，这就是高内聚。改变某个行为，最好做到只在一个地方修改，然后就可以尽快地发布。
2、限界上下文
每一个给定的领域都包含多个
限界上下文，每个限定上下文中的东西都分为两部分，一部分不需要与外部通信，另一部分则需要。每一个
限界上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他的上下文。
另一个关于
限界上下文的定义是：“一个由显式边界限定的特定职责”。
限界上下文就像细胞一样：“细胞之所以会存在，是因为细胞膜定义了什么再细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜”。
（1）、共享的隐藏模型
两个
限界上下文之间可能存在共享的模型。比如：财务部门和仓库可以是两个不同的
限界上下文，它们之间存在共享模型“库存项”。值得注意的是：共享模型存在内部和外部两种表示方式，通常暴露给其他
限界上下文的是共享模型的外部表示。比如，虽然在仓库内部有相应的模型来表示“库存项”，但是我们不会直接把这个模型暴露给财务部门。（也就是所不同
限界上下文共享特定的模型，而不是共享内部表示）。
（2）、模块和服务
对于微服务而言，服务应该清晰地和限界上下文保持一致，如果服务的边界搞错了，后面修复的代价会很大。因此，对于新系统而言，可以先使用一段时间的单块系统，用模块对限界上下文进行建模，同时使用共享和隐藏模型，等系统稳定下来之后，再确定哪些东西作为一个服务划分出去。
（3）、过早划分
过早的划分服务可能带来很多跨服务的修改，这些修改的代价很高，尤其是面对新领域时。对于已有系统的升级改造，可以直接划分服务，对于新领域的系统，建议采用先单体系统实现，再微服务划分。
3、业务功能
考虑组织内的限界上下文时，不应该从共享数据的角度考虑，而应该从业务功能考虑。
4、逐步划分上下文
当考虑微服务的边界时，首先考虑比较粗粒度的上下文，然后当发现合适的缝隙后，再进一步划分出那些嵌套的上下文。比如：粗粒度的仓库上下文，可以包含：订单处理、库存管理、货物接受等嵌套的上下文。
5、关于业务概念的沟通
微服务之间如何就同一个业务概念进行通信，也是一件很重要的事情，在组织内部应该共享相同的术语和想法，同时这些术语和想法应该反映到服务的接口上。
6、技术边界
有时使用技术接缝（边界）进行建模也是可以的，比如说利用地理位置、组织结构等信息。但这不是首选方式。