DDD切入点3 - 领域模型设计
这部分内容，我想学习DDD的人都很熟悉了。DDD原著中提出了很多实用的建模工具：聚合、实体、值对象、工厂、仓储、领域服务、领域事件。
划分好边界上下文，通常每个子域（sub domain）对应一个边界上下文（bounded context），同一个边界上下文中的概念是明确的，没有任何歧义；
这样的架构有其灵活之处，例如对于TP数据库和AP数据库都可以各自选择最好的方案，而且实现了TP/AP负载的完全隔离。但是其缺点也是显而易见的。
In-Memory Column Index使用行列混合存储技术，同时结合了PolarDB基于共享存储一写多读的架构特征，其包含如下几个关键的技术创新点：
因此设计一个一体化的存储引擎能同时服务OLTP型和OLAP型负载非常具有挑战性。目前市场上HTAP存储引擎做的比较好的只有几家有几十年研发积累的大厂
在MySQL插件式的存储引擎框架的架构下，增加列存支持最简单方案是实现一个单独的存储引擎，如Inforbright以及MarinaDB的ColumnStore都采用了这种方案。而PolarDB采用了将列存实现为InnoDB的二级索引的方案，
，其基本只受限于服务器可用的IO吞吐速度和可用CPU资源。该操作是一个online-DDL过程，不会阻塞在线业务的运行。
该方法在诸多Research及Industry领域的工作中都被借鉴并使用，并日益成为分布式数据领域一体化HTAP的事实标准方案。但是应用这个方案的前提是用户需要迁移到对应的NewSQL数据库系统，而这往往带来各种兼容性适配问题。
同时Iterator执行模型也无法充分发挥现代CPU提供的SIMD指令来做执行加速。
执行引擎只能串行执行，无法发挥现代多核CPU的并行话能力。
首先利用传统匹配算法Sift自动生成模型所需的训练数据，完成模型的冷启动；并且在模型上线后，对线上人工作业结果进行自动挖掘，并组织成训练数据，以迭代模型优化。
