DDD是不是過度工程理論?

不在CRUD軟體中？
無論我們選擇何種實現，軟體都是業務抽象。當我們選擇CRUD實現時，我們打賭未來的軟體將具有很少的功能。我們打賭我們不需要很多抽象。由於領域的認知負荷將保持低水平，這意味著我們可以將業務邏輯與技術術語混合，而無需構建難以管理的軟體。

根據我的經驗，許多應用程式都是以簡單的CRUD開始的，但它們很快就發展成為對業務更復雜和有用的東西。不幸的是，我們將它們編碼為簡單的CRUD，這導致了大量的混亂。當然不是故意的，日復一日地增加一點複雜性使得很難抓住解決方案的整體複雜性。我們是沸水的青蛙而不自知。

過度工程理論
挑戰在於找到在什麼時候我們的簡單CRUD應用程式成為更復雜的業務應用程式？

我的理論是，我們一直在考慮戰術DDD過度工程的模式。因為我們無法感受到我們日復一日建立的軟體的複雜性。但是當我們開始另一個專案時會發生什麼？肯定願意從頭開始重寫整個軟體。

尋找拐點
我們想要找到實施戰術DDD模式變得有趣的時候，儘管它有成本。

解決方案的一部分可能是檢查新來者需要多長時間才能進入生產級別工作編碼？當這個過程時間太長時，說明還有改進的餘地，而戰術模式可以幫助降低程式碼複雜性。幫助提高新人快速進入生產能力的效率。
另一種解決方案可能是要求不同的DDD專家進行一些稽核，但可能會更昂貴。
一個更簡單的解決方案可能是假設軟體將變得更加複雜。這意味著我們應該日復一日地研究哪種戰術模式能夠滿足我們的需求。

請記住，戰術DDD模式是一個全世界的實踐，全部使用所有這些模式是不可取的。在合適的時間挑選好的又是困難的。

我什麼時候應該使用戰術DDD模式？
我沒有一個明確的答案，只是一個經驗觀察：我已經看到無數的軟體以CRUD方式實現，這將透過DDD戰術方法得到極大改善。我已經看到沒有使用戰術DDD方法實現的軟體可以透過CRUD實現大大改進。


“如果你認為好的設計是昂貴的，你應該看看糟糕設計的成本。”