DDD — 別懷疑，你的業務應用最重要！
Domain Driven Design 一直以來都被認為是一種軟體開發的機制，我認為這個假設反而侷限了它的用途。就我自己的實務經驗而言，軟體開發需要大量通靈能力的根因多數在於，應用領域的人員時常沒有意識到，他的應用領域才是最重要的核心事務，所有資訊技術、應用工具都是次要的事。
本篇不談技術細節，以下實務觀念不需要特定技術，想瞭解基礎知識的朋友可以閱讀：
Domain Driven 的思考是簡化了這些設計的方向。試想，如果拋開了資訊系統，「我可以實踐一次這個需求嗎？」
例如我可能不會電腦打字，而我要設計一份試題，製作一份考卷。在電腦不普及的年代，都是自己手寫整份試題，有影印機就影印多份使用，也有老師是現場書寫黑板來完成。
在這樣的例子裡，核心領域是設計試題的能力與方法，其他如電腦打字技術、影印機設備等都是次要甚至不是必要的。相反來說，如果有這樣的需求，卻說不出怎麼設計試題，那麼，準備電腦、影印機、甚至聘請打字員，這些準備即使再先進，都完全無法解決實際的問題。
進一步地說，設計試題這項業務應用的領域知識（Domain），才是決定這整件事的天花板和實作的可能性。
專注本業，業務優先
有些資訊人員可能時常抱怨其他同仁資訊能力不佳，我對這點持相反的意見，多數情況反而是，業務應用同仁未能清晰地瞭解並實作他的領域需求。如前文的例子，這時候如果糾結在資訊系統的話，要讓整件事往前走，根本是緣木求魚。
緣木求魚另一個說法就是「瞎做」。大家都很努力了，但結果不如預期。很可惜的是，這在職場上並不罕見。
我的建議是，在面對比較複雜的問題，先拋下資訊系統，先一起「紙上談兵」，讓有業務想法的同仁或主管先模擬全程執行一次，簡化整個問題。再次強調，資訊系統是次要的機制，用於「輔助」真正的應用服務。
資訊式管理，降低領域落差
上面好像講得很簡單，但現實上卻是需要到處通靈，到底是哪裡出了問題？我認為的根因在於業務資訊的管理不足而造成的領域落差。例如我要製作投資系統，卻不懂得均線的意義，如果要實作技術分析的話，就很容易做不出想要的功能，或設計了難以進行統計運算的資料結構。
希望同仁能夠更往前一步，其中一個有效的方式就是主動提供更多的資訊，不論是具體的解決辦法或是開放各種領域資訊，都有機會能夠找到突破的關鍵點。
具體上，軟性的政策可以多辦理實作及知識分享的活動，每一個成員至少在資訊的取得上的機會一致時，落差會逐步縮小；擁有權力者，只要願意善用自己的權力和智慧，能夠做到更好更有效率是理所當然的事。再者，資訊系統能被實作出來，也是人教（寫程式）出來的，人的領域智慧才是資訊系統的設計的依據。
資訊式管理的進步，是需要搭配企業文化的，不會有標準的作法，但只要企業中的每一個人都能擁有嘗試的可能性的話， 就更有機會找到適合的方法。能夠引領企業進步，擁有領域知識的同仁才是關鍵，資訊技術是無法獨自前進的。
善用資訊技術，倍增核心能力
當領域技術能夠常態地被分享且實踐的時候，各種資料庫、微服務、大型系統軟體、分散式運算、巨量資料分析，都開始可以一一對應到實際的業務應用。你不會 over-design，因為 business model 是清晰的；實作上的猶疑減少，系統及組織運作的效能就會加快。
工作在執行上可能需要明確的權責界線，但在討論交流形成方案時則不應該如此。例如行銷規劃人員進行行銷分析，不吝和資訊人員分享分析邏輯與方法，資訊人員也可以公開技術架構和演算法，關鍵在於共同找到有效的執行方法，最後的只剩下，誰可以做就由誰來執行，業務順暢，把餅做大才是最重要的事。
資訊透通了之後，如果大家都不會做，就不要浪費時間，盡早放棄；如果大家都可以做，那就有機會做得更好，還可以互相備援。
別懷疑，你的業務應用最重要！
現在的資訊技術越來越多，系統越來越複雜，流程簡化與資源共享會是資訊系統設計上的一大重點，但永遠不會比業務應用更重要。只要規劃設計上有疑慮時，Domain Driven Design，能協助你重新聚焦到「Domain」的真實需求在哪裡。
對技術發展而言，有利於簡化實作與資源。
對業務應用而言，有利於專注服務與市場。
對策略規劃而言，有利於確立標的與方向。
讓你的 Domain 領導資訊技術發展，將會是更合理也更有效率的方法。
