過去我們想到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在這裡的意義，可能會有更深的探討，以後再說。待續神馬的沒有了，以上。