我們一提及領域建模，就好像回到了石器時代。然而這個謎題至今還未解決，就好像穴居人的生存方式，我們只能猜測、推測以及演繹，卻不能真實復現。
Martin Fowler的《分析模式》總結了諸多領域分析模式，Eric Evans開創了領域驅動設計的辦法，至於還要老的CRC方法，用例驅動，ICONIX方法以及稍新一些的四色建模法，都在嘗試領域模型的建構，結果仍然差強人意。
這個問題或許是Mission Impossible，因為領域邏輯其實是一個復雜系統，系統中的模型如三體一般互相影響，卻又隱沒在混沌中，並不真實清晰地凸顯出來。
在許多項目中，我多數采用混用手法進行建模，CRC、用例驅動、領域驅動以及四色建模，什么適合就選擇什么樣的手法。可是到了最后，似乎還是憑借着經驗在跟着感覺走。沒有教會領域建模的方法，只有可意會不可言傳的感覺。之所以還要提方法，不過是事后諸葛亮而已。
幾年前接觸到CQRS（Command Query Responsibility Separation）模式，為我隱約打開了一扇窗，只是窗外的風景有些模糊，不敢跳出去。繼而是函數式思想每時每刻在顛覆我舊有的設計思想，一步一步地侵蝕着OO的陣地。我沒有放棄OO這個陣地，但我覺得攻守的布局可以豐富些，不拘一格才能更好地解決敵人（需求）。
最近在使用React和Redux開發前端，所謂Pure Component以及Redux的reducer思想好像一陣大風，刮去了窗外朦朧的霧綃，風景變得逐漸清晰起來。領域世界的建築牆上，其實刻滿了“狀態”兩個字！
岔開一筆談談另外的印象。我在了解Datomic數據庫的架構設計思想時，被這么句話驚呆了：
Datomic將數據庫視為信息系統，而信息是一組事實（facts），事實是指一些已經發生的事情。鑒於任何人都無法改變過去，這也意味着數據庫將累積這些事實，而非原地進行更新。雖然過去可以遺忘，但卻是不能改變的。這個不變性（immutability）帶來了很多重要的架構優勢和機會。
醍醐灌頂啊，這不是設計，而是哲學！
讓我們再想想UML里面的狀態圖以及工作流中著名的“狀態機（State Machine）”。或許我們在建模中很少使用狀態圖，然而讓我們開開腦洞，你是否覺得：任何業務邏輯其實都可以轉換成狀態的遷移？
再看看四色建模中的“時標性對象（moment-interval）”，根據徐昊同學對四色建模的解構，時標性對象是建模的起點，這類對象的共同特質在於它在時間線中留下了不可磨滅且不可更改的足跡。根據Datomic哲學思想，顯然，曾經存在的這些足跡或許可以湮滅，但存在的事實卻不可湮滅。於是，我們可以對這些足跡進行“追溯”，這就是所謂的“Event Sourcing”了。
是什么導致事件（Event）產生的？回到CQRS模式，就是Command；而在用例驅動的語境中，就是用例（Use Case）；跳到函數式思想，則可以視為函數。當然，你也可以認為它是對象的行為，但如果我們將Command以及Event都視為不變的對象呢？在Scala中，它們都是Case Class。
然則，這些概念的本質可否認為就是“狀態”世界的各種表征呢？
觸摸到“真相”了嗎？
然而The Matrix中的墨菲斯卻說：
真相是你是一個奴隸，尼奧。你，和其他所有人一樣，生來受奴役……你給關在一所監獄里，這監獄你無法聞及，無法品嘗，無法觸摸。這是你頭腦的監獄。
會否我們對領域世界的思考，其實就是頭腦的監獄？
柏拉圖提出過一個著名的洞穴隱喻。他將不懂哲學的人比喻為被關在洞穴中的囚犯，這些囚犯因為被鎖着，所以只能看着眼前的牆壁，不能轉頭。他們的背后生着一堆火，他們只能看到牆上自己和其他東西的影子。他們無法回頭，不知道有火，便以為牆上的影子是實物。某一天，一位囚犯逃離了洞穴，並發現了真相，發現自己以前被影子騙了。如果是哲學家，他定會回到洞中將真相告訴大家。但是在別人眼中，他肯定是傻子。
故而，我無法解答這是否“真相”，或許我以為找到了，其實不過是火堆將領域建模的方法投影到牆上，而我湊巧是那個被鎖着的囚犯。
行文至此，其實我僅僅提出了問題。如果你覺得我的思緒一片混亂，我會欣然，因為你讀懂了，我正是在清晰地描述一路走來混亂的思維過程。我打算信步而行，搖頭晃腦只是為了觀賞兩邊的風景。現在是春天，路畔的花園粉色桃花白色梨花開了，或許還有櫻花，因為零落的一片一片花瓣在水里有些哀傷。風景太好，我不忍走到終點，改天繼續說說我的思考片段罷。