我们一提及领域建模，就好像回到了石器时代。然而这个谜题至今还未解决，就好像穴居人的生存方式，我们只能猜测、推测以及演绎，却不能真实复现。
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中的墨菲斯却说：
真相是你是一个奴隶，尼奥。你，和其他所有人一样，生来受奴役……你给关在一所监狱里，这监狱你无法闻及，无法品尝，无法触摸。这是你头脑的监狱。
会否我们对领域世界的思考，其实就是头脑的监狱？
柏拉图提出过一个著名的洞穴隐喻。他将不懂哲学的人比喻为被关在洞穴中的囚犯，这些囚犯因为被锁着，所以只能看着眼前的墙壁，不能转头。他们的背后生着一堆火，他们只能看到墙上自己和其他东西的影子。他们无法回头，不知道有火，便以为墙上的影子是实物。某一天，一位囚犯逃离了洞穴，并发现了真相，发现自己以前被影子骗了。如果是哲学家，他定会回到洞中将真相告诉大家。但是在别人眼中，他肯定是傻子。
故而，我无法解答这是否“真相”，或许我以为找到了，其实不过是火堆将领域建模的方法投影到墙上，而我凑巧是那个被锁着的囚犯。
行文至此，其实我仅仅提出了问题。如果你觉得我的思绪一片混乱，我会欣然，因为你读懂了，我正是在清晰地描述一路走来混乱的思维过程。我打算信步而行，摇头晃脑只是为了观赏两边的风景。现在是春天，路畔的花园粉色桃花白色梨花开了，或许还有樱花，因为零落的一片一片花瓣在水里有些哀伤。风景太好，我不忍走到终点，改天继续说说我的思考片段罢。