强调领域模型是整个系统的核心，领域模型也是整个系统的核心价值所在。每一个领域，都有一个对应的领域模型，领域模型能够很好的帮我们解决复杂的业务问题。
而那时如果你再想重构模型，那要付出的代价会比一开始重新开发还要大，因为你还要考虑兼容历史的数据，数据迁移，如何平滑发布等各种头疼的问题。所以，就导致我们最后天天加班。
轻量
服务端一般都是使用很重的客户端 SDK 封装了很多功能和特性，然而终端因为运行环境受限且庞杂必须使用轻量简洁的客户端 SDK。
导致我们没办法直接针对这个大的领域进行领域建模。所以，我们需要将领域进行拆分，本质上就是把大问题拆分为小问题，然后各个击破的思路。
但不是绝对的，当一个领域，我们的关注点越来越多，每个关注点我们关注的信息越来越多的时候，我们会不由自主的去进一步的划分子域。
梳理业务场景：梳理出领域内的核心业务场景，比如电商平台中的加入购物车、提交订单、发起付款等核心业务场景；
梳理业务流程：梳理出领域内的关键业务流程，比如订单处理流程，退款流程等；
这样的架构有其灵活之处，例如对于TP数据库和AP数据库都可以各自选择最好的方案，而且实现了TP/AP负载的完全隔离。但是其缺点也是显而易见的。
MySQL的SQL执行引擎基于流式迭代器模型(Volcano Iterator)实现, 这个架构在工程实现上依赖大量深层次的函数嵌套及虚函数调用，在处理海量数据时，
In-Memory Column Index使用行列混合存储技术，同时结合了PolarDB基于共享存储一写多读的架构特征，其包含如下几个关键的技术创新点：
在PolarDB的存储引擎（InnoDB)上新增对列式索引（Columnar Index）的支持
。流计算系统中的数据一致性一般是用消息处理语义来定义的，如某引擎声称可以提供「恰好一次（Exactly-once Processing Semantics）流处理语义，
