尽量最小化的自包含原则

自包含不光是从开发不会造成相关问题的角度出发，也会布署的扩展延伸有关，一但相关，其实延伸是有些痛苦的。

我们现在能做到微服务级别就可以了。当然，微服务也有大小。

微服务是含独立持久化的。

就是尽量保证微服务对其实的微服务的依赖性降低，最好当然是不依赖。

从设计的思路上考虑，最好是先把大的对象例出来。

然后是对象的分类，这里分为内置的和用户定义的两部分。

然后是根据业务的行为，分析出对象的各种状态。

状态经常是会变化的，分类一般不太会。

这里可以从对象的生命周期的时间轴去看，不同的生命周期，就算是同一个对象，也是可以分在两个微服务中的。

尽量保证一个业务的行为，可以在微服务中完成一个小的闭环。

前面提到了尽量自包含，但实际上是很难的。

不同业务之间，都会依赖一些共享的对象以及它的分类及状态。

各个微服务中，要允许也一定会有冗余的状态或是持久化。

要把这些共享依赖的东东，做个分类，采用不同的技术用段处理。

根据业务性质的不同，可分为即时和非即时性的二类或是当中再加一类。

另外也可分为强一制性及非强一致性，或者是从CAP的角度去分。

关于抽象性，给个例子：

设备的状态

一层，设备只有ON 和OFF。

对应着 ON，再分类成，生产中，待料中，测试中等，状态。

对应着OFF，会有维护中，停机中等，，，，，