好的服务
松耦合（Loose Coupling）
能够独立修改及部署单个服务而不需要修改系统的其他部分
尽可能的少知道与之协作的那些服务的信息
限制不同形式调用的数量
高内聚（High Cohesion）
相关的行为放在一起，把不相关的放在别处
改变某个行为的话，最好能够只在一个地方进行修改，然后就可以尽快的发布
找到问题域的边界确保相关的行为能放在同一个地方，并且服务间尽量用松耦合的形式进行通信
限界上下文（bounded context）
任何一个给定的领域都包含多个限界上下文，每个限界上下文中的东西（模型）分成两部分，一部分不需要与外部通信，另一部分则需要
每个上下文都有明确的接口，决定了暴露哪些模型给其他上下文
一个显式边界限定的特定职责
http://blog.sapiensworks.com/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx
细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜
共享的隐藏模型
共享模型会在多个不同的进程中使用，并且在每个限界上下文中都会存在相应的实体，不过，这些实体仅仅是在每个上下文的内部表示而已
共享模型而不应该共享内部
模块和服务
按照限界上下文，使用模块对其进行建模，同时共享和隐藏模型
成为绝佳的微服务候选
微服务和限界上下文保持一致
先使用一段时间单模块系统，等系统稳定后，在确定把哪些东西作为服务划出去
过早划分
过早将一个系统划分成微服务的代价非常高，尤其是面对新领域时
很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务简单的多
业务功能
在考虑组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从上下文能够提供的功能来考虑
先考虑上下文是做什么的，然后再考虑需要什么数据
业务概念的沟通
修改系统的目的是为了满足业务要求
基于业务领域的软件建模不应该只限于限界上下文的概念
组织内部共享的那些术语和想法，也应该被反映到服务的接口上
以跟组织内通信相同的方式，来思考微服务之间的通信形式是非常有用的
通信形式在整个组织范围内都非常重要
技术边界
按照技术边界建模并不总是错误的，但是，不应该作为考虑的首要方式
