关于存储层总是放在底层的思考

过去我们想到3层模型、领域分层，然后总想到存储层总放在底层，或许不是只是单单的存储层。

这种思考定势是先入为主，还是自然习惯呢？这里我提出一种假设，若果存储层（数据库）只是一个页面，所有持久化都认为是一种单纯的输出，这是一种怎样的情况呢？或者有人会问“存储层”并不存在所谓的“请求”，它是被动方，是的，但我们能不能想象成是一个“阉割”的页面呢？

试想这么一个抽象：除去业务系统运算外，其他都是输入输出。（是一种脱离数据库为中心思维，也算是函数思维的一种表现）

于是乎我们有了跟以前结构不同的两层结构，而这种结构可以很轻易地将进行拓扑扩展。

或与还是有人不能很明白这结构，那么具个更贴近现实的例子：

JSP -> Action -> Service -> ... -> Dao/Repository

这是很常见的传递方式，那么若果如下呢：

JSP/Action <->
//---------------- Service/Logic
Dao/Repository <->

可能会有人说这跟过去没什么两样，这当然，因为我们没有改掉过去对每层的定义。可能甚至会有人认真看会发现不合理的地方，毕竟，这只是一个引子。其实有经验的人应该会发现，Service/logic不再调用其他东西，而是单纯地被调用。是的，这就是引入函数思维的地方，Service是逻辑表达的地方，一旦调用其他技术，肯定会被入侵，我着重说：肯定，别抱有妄想。“调用”意味着“要处理”，也就引来了与业务逻辑无关的技术处理。

过去我们常喊要领域纯净，不让其他技术入侵，能让他实现DSL描述，我想不改变现有框架是不可能实现的（或者改变现有定义）。

若想纯净，则可能要发生如下变化：

JSP <->
//---------------- Action <-> Service/Logic
Dao/Repository <->

或者变种（即把service不再为逻辑表达的地方，而是单纯的技术Service）

JSP/Action <->
//---------------- Service <-> Logic
Dao/Repository <->

而代码书写的变化是：所有事务都只是在更新状态，而不存在计算，让计算纯净话，这样的话，神马云等都轻易引入。过去“osiv是反模式”，今天可否说“事务service是反模式呢”。

关于monad在这里的意义，可能会有更深的探讨，以后再说。待续神马的没有了，以上。