我们在3.1章节中讲到了需求功能拆分为业务功能和数据功能，业务功能的核心是业务模型。
(相关资料图)
那么在这个架构中，还存在哪些技术问题呢？先梳理一下相关的技术点：
1. 角色管理
经常有人问，角色管理与模型如何交互？
角色管理中的角色权限划分以及对应代码上的角色权限约定，他是数据角色权限模型下的角色功能，我们在做业务建模的时候，需要将角色权限模型和我们的业务模型分开设计，角色权限管理关注的是什么用户在什么条件下可以访问什么资源的问题，业务模型是系统本身的业务流程过程，不要将其合并在一起建模。
权限通常划分为功能权限和数据权限：
功能权限是指谁可以访问这个功能
针对功能权限，我们可以采用SpringBoot Security框架来解决，依赖权限注解来实现。
数据权限是指谁可以访问这些数据
数据权限，是对数据访问层的权限，这个可以开发一个数据权限的框架，根据用户的数据权限查询相关的数据，然后返回数据，再就是通过数据的拦截器，就是数据的查询是完整的查询，然后根据用户的权限适配返回的数据结构。
2. 数据处理
数据处理可以分为多种技术，1是模型的持久化、2是数据转化为模型、3是数据缓存、4数据同步1. 模型的持久化
模型的持久化就是是将模型产生的数据实现保存的逻辑，对于建议将业务模型和数据模型分离，然后通过数据模型和业务模型的适配完成对数据模型的数据填充，然后在通过数据模型的ORM等相关的框架完成对数据的存储。
这里我们会看到经常看到需要对对象做转化Convert处理，有人感觉会比较多余，让本来就简单的业务变个复杂。从而让人产生一个让本来简单的事情，变得复杂化的感觉。我来谈一下为什么这样处理。如果不讲业务模型和数据模型分离开，那么我们的业务模型将会受限于数据持久化的技术过程影响， 这样会污染业务模型的纯净度，会让我们的业务模型在未来的变化过程中受限于技术，因此我们需要将其分离开。我们可以寻找更简化的技术方案，或者自己开发一些模型方来来解决这个问题。
如下为3.2章节的代码：
2. 数据转化为模型
数据转化为模型，是将存储在持久化的数据转化为模型的过程，上述代码中的 public static User convert(UserEntity userEntity)就是做这件事情的。也是由于我们的业务模型和数据模型分离，所以需要有这一步的操作，如果你有更加的技术方式，也可以直接将数据转化为模型对象。
3. 数据缓存
数据缓存我们可能采用redis、ES等相关的技术方案，站在业务模型的角度，其实数据缓存也是一种数据持久化的方式，只是持久化的地方不同罢了。4.数据同步
数据同步我们根据技术的特别分为主动同步和被动同步两种不同的数据同步方式。 主动同步：我们为了某些数据的查询方便会选择性的将部分数据同步在多个地方存储，为了方便查询，这时候我们就可以在数据持久化的过程中对需要通过同步的数据，做同步的处理，实现数据多地的存储。 被动同步：例如为了提升系统的效率，我们将系统的数据库设置为读写分离，那么这样的机制下数据的同步可能是依靠数据库层面的技术或中间价来实现的。这样的过程对于我们技术层面的影响不大。
3.统计分析
数据的统计功能是很多业务系统中所必要的功能模块，统计功能通常也是多变的，我们将数据的统计优化，数据查询，数据呈现转化等技术都作为统计分析技术，这些都与采用的技术的相关性非常高。为了提升数据统计分析能力，我们可能会采用多种方式来应对，我们主要以数据存储角度来分析，咱不考虑数据的使用层面，数据使用层面就是结合相关的数据呈现机制来设计相关的存储方案。
建立缓存或者搜索引擎
通过数据的冗余同步实现数据的快速查询
通过动态的数据存储拦截器实现灵活的数据查询优化机制
4. 事务管理
业务模型的事务，该如何处理？这个也是很多人比较关注的问题。业务模型根据服务的性质也是区分为普通的单服务事务和分布式事务等不同的场景技术来解决。对于单服务的事务，我们依旧可以采用spring的本地事务来支持，同样也可以采用分布式事务。若采用分布式事务时，则更推荐采用分布式事务消息中间件来解决，当然也可以采用分布式事务框架。
对于单体服务的本地事务方案，相信大家都在项目中使用过，这里就不再赘述了。
为什么针对分布式系统采用消息事务方案呢？
我们将数据的持久化层更改为消息事件模型是更容易操作的。
消息事务本身是流式数据，流式数据将更方面未来的数据处理与数据分析。
现有的消息中间件，已经做了很成熟的事务的解决方案
总结
业务与技术分析，就是一种通过空间换时间的方式。在上述提到的四个方面处处都体现了这样的设计理念。
将业务与数据之间的强绑定模式，分割成了业务-流-数据的分离架构，实现以事件流为载体的新模式，迈向事件驱动开发。
