分块云计算

核心提示： 我观察到：当数据库Schema、视图、私有存储过程、公共存储过程、数据访问层，一层层手工编写下来（（为了保证一切都恰如意料，分块云计算(2)，比如性能）），很多时候，这样做意味着避免了大量繁重的工作，让我们有时间投入到真正关心的部分——领域模型本身，就没有多少时间花在业务

我观察到：

当数据库Schema、视图、私有存储过程、公共存储过程、数据访问层，一层层手工编写下来（（为了保证一切都恰如意料，比如性能）），很多时候，就没有多少时间花在业务层上了。于是业务层往往非常薄，不外乎做些左手交右手的工作，捎带若干占位用的注释。

由图1可见，数据存储受到重重防卫，从UI到数据存储经过的保护层不是一般多。然而在多数情况下，由于使用Recordset模式完成从数据库到UI的数据传输，造成数据库Schema严重暴露。而当UI完成修改回传数据的时候，差不多就是直接写入到数据库了……所谓保护不过如此。

引入每一层的依据是“有比没有好”，而不是因为“证明有需要”。违反YAGNI原则的绝佳例子，对吧？

如今，我的典型初始分层方案与以往截然不同。一开始只用一个领域模型层，先把握住我们真正关心的部分，也就是业务问题的解决方案。

然后当有必要的时候才增加层次，比如需要用户界面的时候才会加上UI层。只要合适，UI层甚至可以直接叠在领域模型之上。要是不合适，再考虑别的需要。

接下来，如果我们希望把领域模型持久化到关系数据库，才把这部分需要放入场景中加以考虑。通常用一个对象/关系映射就能解决得很好，大约能自动解决80%的领域模型到数据库的数据映射需求。请看图2。

图2. 时下典型分层一例

我还尝试令数据库Schema成为领域模型反映出来的“结果”，自动生成数据库Schema。这样做意味着避免了大量繁重的工作，让我们有时间投入到真正关心的部分——领域模型本身。（同样的做法还可以用到UI上。）