本文書接上回《為了給Javaer落地DDD，我們不得不寫開源組件》，,關注公眾號（老肖想當外語大佬）獲取信息：
- 最新文章更新；
- DDD框架源碼（.NET、Java雙平台）；
- 加羣暢聊，建模分析、技術實現交流；
- 視頻和直播在B站。
https://mp.weixin.qq.com/s/Nsc3hwl4u9je7DaXsC05mg
背景
我們在《這是DDD建模最難的部分（其實很簡單）》一文中介紹了一個關於“用户-角色”的建模過程，當我們討論“如何分析業務和建模，以在滿足需求的前提下，使得需求和模型的邊界都清晰且一致”這一話題時，發現很多經驗豐富的開發者，總會帶着各種各樣的顧慮和疑惑，“數據庫裏的表關係怎麼處理”，“關聯查詢不就解決問題了嗎？”，“為啥不能關聯查詢？”，“既然有了某某Id，説明它們有關係啊，你為啥説邊界明確？”。
我就在想，這裏的問題到底在哪裏，為什麼我們覺得理所當然的想法，仍然有很多人會覺得困惑，經過和我們團隊夥伴們深入探討，我覺得我們找到了問題所在。
知識的詛咒
我記得在《倚天屠龍記》中有這麼一幕，張三丰現場傳授張無忌太極劍法，教完之後，問張無忌好幾遍：“還記得多少？”，張無忌最後説：“我已經把所有的全忘記了！”，張三丰很高興：“好，你可以上了。”
回到我們軟件設計的場景，我們經驗豐富的工程師，總是會深思熟慮，會考慮性能夠不夠？模型怎麼存到表裏？表結構是否合理？這裏應該一對一關係還是一對多？又或者應該是多對多？這一系列的問題使得大家無法集中精力思考業務的本質是什麼，過早地把注意力放在了技術上，在跟業務專家熱烈溝通客户場景的時候，你的腦海裏卻滿滿的SQL語句怎麼寫。
我想，這大概就是知識的詛咒吧，揹負着沉重的心智負擔，大概率也做不出更準確的判斷。
忘掉數據庫
現在假設科技已經發展到了非常頂級的水準，我們具備瞭如下能力：
- 應用程序的內存無限大；
- 應用程序內存永遠不會丟失；
那麼，我們還需要數據庫嗎？我想，應該不需要了，我們代碼會是怎麼樣的？是不是在內存中構造出模型的實例添加到它的集合容器中，就可以了？
假如不再需要數據庫了，你建模的時候是不是可以忘掉數據庫，把模型看作是一個個獨立的類型實例即可？你的建模思路是否會發生一些變化？那麼在這個背景下，我們重新審視“領域的邊界”這個概念。
假如我們仍然使用之前的文章中提到的準則：“聚合之間不存在相互引用”，那麼你設計出來的結果是不是就會像我們之前推演的那樣，像下圖一樣：
如果你仍然有疑惑，我把具體的類圖也添加進來，你是不是就一目瞭然了：
回到現實
當然，現實是我們的科技並沒有像上面設想的那樣發達，我們最終還是要將模型數據存儲到數據庫的，因此，我們需要ORM框架來幫助我們解決模型的“存取”問題，注意這裏我用到的是“存取”，不包含搜索，搜索的事情，我們可以用更加靈活的解決方案，這涉及到一種叫做CQRS的模式，這又是另一個故事了。
假如我們有一個很強大的ORM，可以幫助我們根據Id，取出模型，我們操作完模型，ORM再幫我們“Save”進數據庫，我們不需要關心這裏面它到底做了什麼，那麼是不是這個ORM也可以幫助我們擺脱“數據庫知識”的詛咒，讓我們在建模的時候專注需求和模型？
結論是什麼
基於上面的推導，我認為有如下結論：
- 數據庫知識，會成為分析需求和建模時候的心智負擔；
- 一個功能強大的ORM，有利於幫助工程師擺脱“數據庫知識”的心智負擔；
- 分析需求的時候，只需要關心需求和模型即可；
那麼，你對上面的結論有什麼看法？你在用什麼樣的ORM？你參與的項目的代碼組織方式，是否讓你可以專注業務？歡迎在文章評論區友善地討論，也歡迎關注我的公眾號（老肖想當外語大佬）以獲得最新的更新。
後續
下一篇，我將介紹一種能夠在各個角色間建立共鳴的建模溝通方法，以使得我們的建模思維可以落地和複製，敬請期待。
