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