【以数据为核心的微服务设计】

1 以数据域为导向

1.1 关于数据域的定义

一组数据的独立性考虑，自洽的数据表集合；

这个域的范围，是基于数据应用的边界；

比如“项目管理”作为一个应用，其数据域，是独立自洽的，如果项目管理应用需要获取其他数据域的数据，那么使用restfulAPI获取相应的数据，但是项目管理的应用，并不依赖于外部数据；也就是说，外部的数据需要被copy一份到项目管理领域中；

用户信息，在项目管理应用中，所需要的用户信息，是用户数据域的一个自己，并非全部。观察项目管理数据域中，需要用到的用户信息，包括了在项目管理中所需要的内容，比如角色，一个人员，在项目管理中的角色和其在组织中的角色是不同的。那么就需要在项目管理中，独立建设角色的设计；此权限，并非是统一登录用户所涉及的权限控制；而是基于对项目的权限。张三，作为组织的员工，是某部门的员工，但是其在项目中，作为项目经理存在，项目经理这个角色，并非是公司组织的角色。

再比如供应商管理，项目管理中，供应商是提供项目支撑的要素，单并非是供应商管理的全部内容；我们需要理清楚，在项目管理中，供应商应该具备哪些数据要素和行为要素。项目管理这个应用需要从供应商管理应用中，引入什么样的数据和调用；是否会更新供应商应用的内容？例如：采购合同的付款条款，是可以因为单一项目而独特的，并不一定采用其标准付款该条款；供应商提供的商品和服务清单，也可能超出了在企业供应商体系中的内容；

数据域的边界定义，是最困难的，任何一个数据域都很难是完全独立，或多或少，都会与外部系统产生数据交互。然而我们依据什么评断数据域的明确边界呢？

比如：生产管理数据域，生产工单，必定是其主要的数据对象；然而，生产工单的顺利执行，依赖于诸多因数，比如：生产物料和设备，我们如何将生产数据域和物料数据域以及设备数据域进行分割，是极其重要的课题；我们可以使用“以生产为核心的设备“，引入设备数据；影响生产的设备域数据是直接的影响，或者可以说，是生产管理者关心的设备信息，包括设备的可用情况，设备的运行过程数据等，然而，设备资产，维修维保的数据则不被引入；

我们考察这个数据域的定义，需要与关键的业务人员了解，作为生产者视角，关注的信息究竟是什么；切不可蔓延边界；

当然，诸多的行业系统的规范和标准，都做出了定义，随着业务系统的复杂化，更多的数据域使用者，关注的内容会越来越宽泛。这必然导致系统设计的臃肿。

这是一个平衡与取舍的问题；

1.2数据域的冗余和同步问题

1.3 数据的时限性

需要用单独一个章节阐述数据的时限性问题；

因为数据的冗余和同步，数据的权限设计都与此相关；如果所有数据都是持久性active，那么此后的逻辑都不成立了，因此，我们考虑的是，具有时限性的数据；

另外，数据的当前active的量级也是衡量基于数据域设计微服务时，需要考虑的内容；

1.3 关于数据权限

我们将数据权限分成2个部分，R读，和W写；

对数据列的权限设计是容易的；我们在逻辑中使用 [field].isReadonly()可以轻松获得；

但是对数据的行权限，也就是对象权限的设计，是依赖于数据的，这使得应用的开发不得不依赖于具体的数据内容和逻辑。在程序语言中，变得非常困难。

我们可以做如下假设：数据对象的读权限是永恒的，而写权限是具有时限性的；我们和数据对象同步设计一个“影子”对象来表达权限，当我们获取一个数据对象的同时，也获取到了一个影子对象，即权限对象，在对数据对象进行写操作时，需要使用权限对象进行判定和约束；同时，我们必须设计对影子对象的注销逻辑，这个注销逻辑是指：我们依据逻辑，评估其影子对象中所有的数据都成为只读权限时，就将这个影子对象消灭。不再占用存储资源；此时，数据对象，将只作为“灰色对象”，只拥有读权限了；

而读权限的设计是明确的，它只依赖于列权限的分配，我们在用户权限中仅仅对列权限做限制即可；

1.4 读写分离策略

读写分离策略是对数据操作效率的改善；

2 应用的单一性和多样性

基于数据域的软件架构，是微服务设计的一个重要改进，将微服务发挥最大功效。

然后，一旦数据域范围的框定，一定会严格限制了应用的多样性，这一部分应该如何考虑？

2.1 单一数据域的多应用

基于一个数据域的应用构建，一般是一个单体的应用系统。随着系统所包含的功能越来越多，会导致系统的复杂性；

因此，确保数据域的边界的严谨性。再次基础上，构建多个应用系统的方式，是解决单体应用的一个好的方法。那么应该如何设计呢？

确定不同应用的单一功能和目标；特别是结合单一用户类型进行系统设计，会有效的降低多个应用之间的耦合性；

例如，我们设计一个酒店预订系统，整个数据域围绕酒店订单开展；那么基于住客的应用功能，可以是独立的。如果想要扩展应用，例如，酒店住客是团队，或者企业长期客户，那么其功能可能是不一样的，然而其对应的后端数据域，并不需要变化，如此，我们就可以建设2个应用，一个是为游客设计的应用，一个是为企业用户设计的应用；甚至，如果再扩展，可以设计为渠道设计的酒店预订系统。仍然都是独立的。然而，当我们作为酒店管理者，通过另外一个角色，酒店预订管理员的身份，或者房源分配的身份来看待这个数据域的时候，我们可以构建一个基于酒店管理员角色的应用。

因此，我们可以看到，以不同的角色构建单一数据域的用户，是一个有效的角度；

另外，我们还可以使用另一个角度构建应用，例如：流程；基于流程的应用是传统的系统构建的方式。但是流程经常会发生变化，我们采用不同的流程扩展应用的时候，可以采用新增流程，而不是增加原来流程的复杂度来迭代系统。流程迭代的好处是，相对稳定，但是其坏处是对数据影响的多寡，造成系统数据的不一致。这个问题需要在设计之初就充分的考虑到。

2.2跨数据域应用

跨数据域应用，只读场景，存在于数据分析；

跨数据域应用，如果具有业务逻辑和回写逻辑，就应该是独立的微服务，

2.3 应用的生命周期

切记，应用的生命周期尽量不要延展，与传统应用相比，基于数据的应用系统，尽量缩短其生命周期。