如上图所示，我们在微服务拆分后，将微服务内部的代码层级主要分为 interfaces、biz、domain 以及 instructure 这四层，分别对应用户接口层、业务层、领域服务层以及基础设施层，
标准协议
服务端正是因为有了重量级客户端 SDK，其封装了包括协议通信在内的全部功能，甚至可以弱化协议的存在，使用者无须感知，而终端场景因为要支持各类庞杂的设备和场景接入，必须要有个标准协议定义。
这个 lookup 查询组件，实际上就是一个 KV 查询，可以理解为是一个分布式内存 KV，但要比分布式 KV 实现难度至少低一个等级。我们回想一下一个分布式 KV 的基本要素有哪些：
但是，很多项目（尤其是互联网项目，为了赶工）都是一开始模型没想清楚，一上来就开始建表写代码，代码写的非常冗余，完全是过程是的思考方式，
然后，还要思考子域之间的联系是什么。那么，我们该如何划分子域呢？我的个人看法是从业务相关性的角度去思考，也就是我们平时说的按业务功能为出发点进行划分。
关于这些建模工具的概念和如何运用我就不多展开了，我博客里也有很多这方面的介绍。下面我再讲一下我认为比较重要的东西，比如到底该如何领域建模？步骤应该是怎么样的？
关于这些建模工具的概念和如何运用我就不多展开了，我博客里也有很多这方面的介绍。下面我再讲一下我认为比较重要的东西，比如到底该如何领域建模？步骤应该是怎么样的？
三家领先的商用数据库厂商，均同时采用了行列混合存储结合内存计算的技术路线，这是有其底层技术逻辑的：列式存储由于有更好的IO效率(压缩,DataSkipping,列裁剪)以及CPU计算效率(Cache Friendly)
由于有一个久经考验的行存系统的存在，列存系统出现任何问题，都可以切换回行存系统响应查询请求。
上述条件可谓有利有弊，这也影响了对PolarDB整个行列混合存储的方案设计。
当一个查询所需要的列都被列索引覆盖时，借助列存的加速作用，可以数十倍甚至数百倍的提升查询性能。
