关于中台的一点思考

1. 技术中台的职责
   中台负责完成最佳实践，提供给业务部门可选使用
   中台负责完成技术底层，提供给业务部门可选使用
   负责完成数据管理的最佳实践，提供给业务部门，数据中台可选使用

2. 数据中台的职责
   对各个业务组业务模型进行整合创建总体层面的业务模型,并完成总体层面业务模型的数据统计，汇总，链路
   不负责业务数据的细节存储，细节由业务部门负责,但可以冗余存储，数据中台主要负责完成总体层面上的数据统计，汇总，链路

3. 业务部门的职责
   3.1 业务中台
   对业务进行数据建模
   对数据中台提供数据提取支持，接口，或者数据中台直接读库
   提供公共类型的业务功能(细粒度)实现，提供给业务部门使用完成业务场景
   提供公共类型的业务场景实现，可选提供给业务部门使用(数据建模不能依赖必须有这部分功能，业务组可能不使用)

   3.2 业务终端
   完成特化的业务场景功能实现
   整合使用业务中台提供的功能完成业务场景

潜在收益是什么？能不能举个例子？例子里必须是这个方案吗？其他方案不行吗？
比如erq，潜在收益是降低代码中的读写逻辑，但是降低代码中的读写逻辑有什么收益，更快的交付？影响交付的瓶颈在实现代码读写逻辑吗？

业务的本质是数据流动
程序功能实际上就是对数据的流动进行引导，让数据已符合业务逻辑的方式进行流动。
事件实际上是触发数据流动的发起端，一个事件发生一般代表了某些数据将要流动到新的方向或地方。
数据存储实际上是对当时流动的某一部分数据进行快照，或者把暂时完成流动的数据保存下来已方便需要继续流动的时候读取出来继续流动。
事件触发执行程序功能，程序功能将事件影响到的数据取出来后对这部分数据的流动按符合业务逻辑的方式进行引导，并在数据流动结束后将数据固化到数据存储中。
update 在这里可以理解为数据从一个地方流动到另一个地方，update 只是这种类型流动的技术表现形式，比如批量修改某批数据的状态可以理解为这批数据从之前的位置(状态1)继续流动到新的位置(状态2).
数据的流动方向是任意的，虽然在特定条件下数据在某一时期大概率以指定的方式流动，但程序实现还是不要过多的假定数据会一直按指定的方向流动

数据有两种类型，一种是价值始终是有效的，一种是价值是有时效性的。
价值始终有效的这部分数据一般会进行存储以方便后续使用时可以再次读取出来，而有时效性的这部分数据一般是作为事件通知給对应使用的人，或者临时存储然后有需要的人在合适的时机进行拉取。

DDD 还有一点比较容易忽视的是要用技术去适配业务，而不是业务去适配技术。
以前的开发模式是识别到一个业务，然后确定数据模型，技术架构，然后在后续迭代的过程中用这个技术架构来实现业务，业务只能基于当前的技术架构来实现，业务来适配技术。
而 DDD 在这方面恰恰相反，DDD 要求你的技术架构使用业务模型来构建，这样在后续迭代过程中业务模型的变更会实时体现到技术架构中，这时候是技术来适配业务模型的技术架构，是技术来适配业务。

两种方式的优劣
业务适配技术
优势
技术演进相对保守，变更没那么多，使用技术架构作为底层比较稳定
业务是基于技术架构提的，所以相对开发周期会快一些
劣势
业务变更比较频繁，市场无时无刻不再变化，当出现技术架构和业务架构不匹配时，容易出现迭代成本高，甚至无法实现的问题，最后只能重构。
技术适配业务
优势
技术架构始终紧跟业务架构，业务出现变更时可以快速体现在技术架构中，技术架构在每次业务变动时都会跟随变动，不会出现攒一大堆需要重构的情况。
劣势
每次业务进行大的调整时技术架构也需要跟着调整，开发周期慢，但是技术架构和业务架构更匹配，平时小需求的开发可能不会慢
迭代过程中容易因为惯性回到业务适配技术这条路上来，最终导致业务架构和技术架构还是不一致，最终又回到了业务适配技术的路上