对局部和全局的问题需要有发现的眼光，更应该有发现未发生问题的能力，哪些是需要治标，哪些需要治本，这个是发现问题的基本判断力。现在系统可能没什么大问题，但你要有发现的眼光，这些问题如果不解决，未来业务可能遇到更严重的问题。
如何提前释放包年包月云盘？
阿里云不支持
• 运行查看具体的数据盘信息。
• 查看/etc/fstab 里面添加的信息是否对应。
说明：不要重复添加挂载信息，否则会导致实例开机重复挂载，系统无法启动。
这个思路，和传统的分析、设计、编码这几个阶段被割裂（并且每个阶段的产物也不同）的软件开发方法学形成鲜明的对比。
什么是驱动（Driven）？
上面其实已经提到了，就是：1）领域驱动领域模型设计；2）领域模型驱动代码实现。
而且更糟糕的是，出来混总是要还的，前期的领域模型设计的不好，不够抽象，如果你的系统会长期需要维护和适应业务变化，那后面你一定会遇到各种问题维护上的困难，比如数据结构设计不合理，代码到处冗余，改BUG到处引入新的BUG，新人对这种代码上手困难，等。
有些时候，需求方，即提出问题的人，很可能自己不清楚具体想要什么。他只知道一个概念，一个大的目标。比如他只知道要做一个股票交易系统，一个灰度发布系统，一个电商平台，一个开发工具，等。但是他不清楚这些系统应该具体做成什么样子。
细化子域
通过上面的两步，我们了解了领域里的知识，也对领域进行了子域划分。但这样还不够，凭这些我们还无法进行后续的领域模型设计。我们还必须再进一步细化每个子域，进一步明确每个子域的核心关注点，即需求细化。我觉得我们需要细化的方面有以下几点：
领域建模的方法
通过上面我介绍的细化子域的内容，现在再来谈该如何领域建模，我觉得就方便很多了。我的主要方法是：
划分好边界上下文，通常每个子域（sub domain）对应一个边界上下文（bounded context），同一个边界上下文中的概念是明确的，没有任何歧义；
首先，在技术上需要维护两套不同技术体系的数据库系统，其次由于两套系统处理机制的差异，维护上下游的数据实时一致性也非常具有挑战。而且由于同步延迟的存在，下游AP系统存储的经常是过时的数据，导致无法满足实时分析的需求。
In-Memory Column Index使用行列混合存储技术，同时结合了PolarDB基于共享存储一写多读的架构特征，其包含如下几个关键的技术创新点：
