現代企業中,非技術人員和技術人員之間的界限開始變得模糊。我看到在一些更加進步的公司裏,技術人員會參與公司業務的決策。而這種決策權,正是由於技術人員運用「讓步的藝術」而獲得的。「讓步的藝術」讓技術人員找到了技術的機會,從而消除了生產環境的約束,創造了更大的商業價值。他們對齊了業務的實際需求,並且可以自主提供滿足這些需求的解決方案。
本文是關於我的故事,其中包含了 DDD 如何幫我更多地學會怎樣解決問題,並幫助人們重新關註解決方案的產生方式,人們是如何溝通和協作的,以及技術人員如何提供解決方案,並識別超出業務同事預期的機會。
這篇文章都是從我自己的角度出發,因此僅限於個人經驗。我不是顧問,也不曾作為合同工工作過,所以我的經驗僅限於電子商務領域。但是在我看來,這些領域已經足夠複雜,從而可以從領域驅動設計的實踐中受益。我不是領域驅動設計藝術的絕地大師[3],也沒有參加過 Eric Evans 的「淑女學堂」[4](有這種學堂嗎?如果真的有,請發給我詳細信息),所以除了說些經驗教訓,我實在給不出其它的金玉良言。
我很慶幸,自己的職業生涯始終處在這樣一個行業,裡面有全世界最慷慨的人。軟體社區非常擅長提供意見、建議和經驗,不過這些都需要放在特定上下文中去理解,當然也要根據其所應用的上下文進行調整。
因此,雖然不能保證我的經驗之談能解決你所有的問題(或任一問題),但希望你能在我多年來的經驗教訓中找出一些東西。這些東西或許可以在你的 DDD 實踐之旅中,起到催化劑的作用。不過,請謹記,這些完全取決於上下文,而本文只描述我個人的上下文。
領域驅動設計既是一種思維方式,也是一系列已按優先順序排序的事項,旨在加速處理複雜領域的軟體項目的開發進程。 ——Eric Evans《領域驅動設計》(2003年)
在談論有關 DDD 的心得,以及對 DDD 的首要原則的看法之前,我想快速回顧一下領域驅動設計的基本概念。因為在我看來,這些概念看似簡單,但經常被誤解。因為細節是魔鬼。