尽量最小化的自包含原则
自包含不光是从开发不会造成相关问题的角度出发，也会布署的扩展延伸有关，一但相关，其实延伸是有些痛苦的。
我们现在能做到微服务级别就可以了。当然，微服务也有大小。
微服务是含独立持久化的。
就是尽量保证微服务对其实的微服务的依赖性降低，最好当然是不依赖。
从设计的思路上考虑，最好是先把大的对象例出来。
然后是对象的分类，这里分为内置的和用户定义的两部分。
然后是根据业务的行为，分析出对象的各种状态。
状态经常是会变化的，分类一般不太会。
这里可以从对象的生命周期的时间轴去看，不同的生命周期，就算是同一个对象，也是可以分在两个微服务中的。
尽量保证一个业务的行为，可以在微服务中完成一个小的闭环。
前面提到了尽量自包含，但实际上是很难的。
不同业务之间，都会依赖一些共享的对象以及它的分类及状态。
各个微服务中，要允许也一定会有冗余的状态或是持久化。
要把这些共享依赖的东东，做个分类，采用不同的技术用段处理。
根据业务性质的不同，可分为即时和非即时性的二类或是当中再加一类。
另外也可分为强一制性及非强一致性，或者是从CAP的角度去分。
关于抽象性，给个例子：
设备的状态
一层，设备只有ON 和OFF。
对应着 ON，再分类成，生产中，待料中，测试中等，状态。
对应着OFF，会有维护中，停机中等，，，，，
