人們經常談論優秀設計和糟糕設計。你的設計屬於哪一種？
有很多軟件開發團隊的設計從來經不起思考。他們採用一種我稱之為“任務板挪卡” 的方法來代替設計。團隊有一個開發任務清單，比如 Scrum 產品待辦列表，其中的任務被張貼在“任務板”上，然後他們可以將一張便利貼從“任務板”上的“待辦”泳道移動到“進行中”泳道，這就是“任務板挪卡”。
產品經理提出待辦項（任務），然後來一次“任務板挪卡”，這便構成了關於設計的全部“真知灼見”，剩下的就交給程序員大神們去瘋狂輸出代碼。很少有團隊會這樣做，如果真的這樣做了，業務就會為這些不存在的設計付出最高昂的代價。
這種情況常常是因為團隊必須按照苛刻得近乎殘忍的時間表去發佈軟件，管理層只會使用 Scrum 控制交付節奏，卻對它最重要的信條之一：知識獲取 （Knowledge Acquisition） ，視而不見。
在我獨立進行諮詢和培訓的經歷中，經常會遇到相同的情境。軟件項目如履薄冰，所有團隊成員都在努力地維護著系統穩定，每天面對著代碼和數據打補丁。以下是我發現的一些潛在問題，有趣的是，DDD可以幫助團隊輕而易舉地避免其中的一部分問題。我先從高層次的業務問題開始，然後再討論技術相關的問題：
- 軟件開發被視為成本中心而非利潤中心。這通常是因為從業務的視角來看計算機和軟件技術是必要的消耗而不是戰略優勢的重要來源（不幸的是，在根深蒂固的商業文化下，這種觀念不太可能被轉變）。
- 開發人員熱衷於技術並通過技術手段解決問題，而不是深入思考和設計，這會導致他們孜孜不倦地追逐技術上的新潮流。
- 過於重視數據庫，大多數解決方案的討論都是圍繞數據庫和數據模型，而不是業務流程和運作方式。
- 對於根據業務目標命名的對象和操作，開發人員沒有給予應有的重視，這導致他們交付的軟件和業務所擁有的心智模型之間產生巨大的分歧。
- 上面的問題一般是業務協作不順暢而導致的。業務干係人常常浪費大把時間閉門造車以實現各種無人問津的需求，或者只有一小部分能被開發人員採用。
- 頻繁而又要求精準的項目估算會佔用大量的時間和精力，導致軟件交付延期。開發人員使用“任務板挪卡”而非考慮周詳的設計導致他們造出了一個個“大泥球”，而不是業務驅動下恰當的分離模型。
- 開發人員在用戶界面和持久層組件中構建業務邏輯。此外，開發人員也經常會在業務邏輯當中執行持久化操作。
- 數據庫查詢會時常出現中斷、延遲、死鎖等問題，阻礙用戶執行時間敏感型的業務操作。
- 項目中存在錯誤的抽象級別，表現為開發人員試圖藉助過度概括的方案滿足所有當下以及臆想出來的未來需求，而不是解決實際而又具體的業務訴求。
- 在緊耦合服務群中，當一個服務執行操作時，該服務直接調用另一個服務並引發一個對等操作。這種耦合會經常破壞業務流程和未達成一致的數據，更別提這樣的系統會有多難維護了。
這一切都似乎發生在“設計無法帶來低成本的軟件”的觀念下。而這時常是出於商業上的簡單考慮，軟件開發人員並不知道還有其他更好的選擇。“軟件正在蠶食整個世界”，對你而言重要的是，軟件不但可以蠶食你的利潤，也可以提供一場利潤盛宴。
你一定要明白，臆想出來的“不做設計能省錢”的觀念簡直是一個謬論，它已經巧妙地愚弄了那些不思考周詳設計而只會對軟件交付施壓的人們。這是因為設計仍然會從每個開發人員的腦海流淌到在鍵盤上不斷敲打著代碼的指尖之中，這些設計並不需要來自其他地方的輸入，包括業務。以下這句話可以很好地總結這種現象：
關於設計是否必要或是否負擔得起的問題根本都沒有問到點上：設計是不可或缺的。除了優秀設計就是糟糕設計，根本不存在“不做設計”一說。儘管 Martin 先生的這句評論並非專門針對軟件設計，但這同樣適用於我們的技藝，考慮周詳的設計同樣無可取代。在剛才的情景中，如果一個項目由五名開發人員參與，那麼“不做設計”將會產生五種不同的設計。也就是說，在沒有任何真正領域專家的協助下，你開發出來的軟件將會混雜著五種不同的、虛構出來的、對業務語言的詮釋。
事實上：無論承認與否，我們都是在構建模型。
這就好比修建道路。一些歷史悠久的道路最開始是跑馬車的，經過歲月的碾壓最終變得年久失修。為了滿足少數人的需要，它們被加入了不明所以的轉彎和岔路，並被改造得迂迴曲折。在某個時刻，它們會被剷平並且會被重新建設，為的是讓越來越多的旅客感到舒適。這些將就湊合的道路到現在還有人路過，不是因為它們設計良好，而僅僅是因為它們存在著而已。如今很少有人能夠了解行走在這些道路上彆扭不堪的原因。而現代道路都會依據人口、環境以及可預測的流量來規劃和設計。兩種類型的道路都會被建模。一種模型只是做了最基本、最簡單的思考，另一種則最大程度地發揮了聰明才智。軟件建模也可以從這兩種角度出發。
如果你擔心周詳的設計會帶來高昂的軟件開發成本，那麼設想一下，將來為了維護甚至修繕一套糟糕設計的軟件就需要付出更為昂貴的代價。當我們把軟件作為你的公司與其他公司之間的差異，並依靠它帶來可觀的競爭優勢時，尤其如此。
“有效（Effective）”一詞和“優秀（Good）”意義相近，它能更準確地表達我們應該在軟件設計中努力追求的目標：“有效設計”（Effective Design）。有效設計可以滿足商業組織希望藉助軟件超越競爭者的訴求。它可以驅動企業去思考哪些核心業務必須成為其競爭力，還可以指引構建正確軟件模型的方向。
Scurm 中的知識獲取是通過不斷的試驗及協作學習完成的，這被稱為“知識付費”（Essential Scrum）。知識永遠都不是免費的，但在《領域驅動設計精粹》中，我將提供一些方法幫你更快地獲取它們。
如果你對有效設計的影響仍心存疑慮，別忘了那位曾洞察其重要性的人：
絕大部分人錯誤地認為設計只關乎外觀。人們只理解了表象——將這個盒子遞給設計師，告訴他們：“把它變得好看一些!”這不是我們對設計的理解。設計並不僅僅是感觀，設計也是產品的工作方式。 ——喬布斯軟件開發中，有效設計最為重要。如果只有一個選擇，那麼我首推有效設計。
本文節選自《領域驅動設計精粹》（Domain-Driven DesignDistilled）一書，該名家名著現已全面上市，點擊擴展鏈接瞭解詳情。
本書適用於對快速學習DDD核心概念和主要工具，表面上看最主要的讀者是軟件架構師和開發者，因為他們是在項目中實踐 DDD的人，也跟容易發現DDD的美妙之處。然而，本書同樣可以幫助高管、領域專家、經理人、業務分析師、信息架構師和測試人員快速理解這一主題並認識到其獨特價值。閱讀原文將帶你領略DDD大師Vernon的這部新作，它必將成為國內眾多團隊快速引入和落地DDD的絕佳指導。
閱讀更多 博文視點Broadview 的文章
