领域建模的目标针对我们在领域中所关心的问题，即只针对核心关注点，而不是整个领域中的所有问题；
领域模型在设计时应考虑一定的抽象性、通用性，以及复用价值；
通过领域模型驱动代码的实现，确保代码让领域模型落地，代码最终能解决问题；
领域模型是系统的核心，是领域内的业务的直接沉淀，具有非常大的业务价值；
技术架构设计或数据存储等是在领域模型的外围，帮助领域模型进行落地；
DDD切入点2 - 理解领域、拆分领域、细化领域
梳理领域概念：梳理出领域内我们关注的概念、概念的关系，并统一交流词汇，形成统一语言；
梳理业务规则：梳理出领域内我们关注的各种业务规则，DDD中叫不变性（invariants），比如唯一性规则，余额不能小于零等；
本文阐述了IMCI背后技术路线的思考和具体方案的取舍。PolarDB MySQL 列存分析功能即将在阿里云上线，敬请期待。
一 MySQL生态HTAP数据库解决方案
在分析场景经常需要访问某个列的大量记录，而列存按列拆分存储的方式会避免读取不需要的列。其次列存由于把相同属性的列连续保存，其压缩效率也远超行存，通常可以达到10倍以上。
最后列存中大块存储的结构，结合MIN/MAX等粗糙索引信息可以实现大范围的数据过滤。所有这些行为都极大的提升了IO的效率。在现今存储计算分离的架构下，减少通过网络读取的数据量可以对查询处理的响应时间带来立竿见影的提升。
传统MySQL的表达式计算体系以一行为一个单位的逐行运算，一般称其为迭代器模型实现。由于迭代器对整张表进行了抽象，整个表达式实现为一个树形结构，其实现代码易于理解，整个处理的过程非常清晰。
列存的设计无需考虑事务并发对数据的修改, 数据的unique check等问题，这些问题在行存系统中已经被解决，而这些问题对ClickHouse等单独的列存引擎是非常难以处理的。
由于有一个久经考验的行存系统的存在，列存系统出现任何问题，都可以切换回行存系统响应查询请求。
上述条件可谓有利有弊，这也影响了对PolarDB整个行列混合存储的方案设计。
表现为Index的列存
在MySQL插件式的存储引擎框架的架构下，增加列存支持最简单方案是实现一个单独的存储引擎，如Inforbright以及MarinaDB的ColumnStore都采用了这种方案。而PolarDB采用了将列存实现为InnoDB的二级索引的方案，主要基于如下几点考量：
采用这种数据组织方式一方面满足了分析型查询按列进行批量扫描过滤的要求。另一方面对于TP型事务操作影响非常小，写入操作只需要按列追加写到内存即可，删除操作只需要设置一个删除标记位。而更新操作则是一个标记删除附加一个追加写。列存可以做到支持事务级别的更新同时，做到几乎不影响OLTP的性能。
