追尋完美設計是從一開始就伴隨著領域驅(qū)動設計（DDD）的常見問題，但DDD不是為完美主義者而生的。最近在阿姆斯特丹的DDD歐洲會議上，Eric Evans在其演講中指出，為了停止這種追求，你需要對如何創(chuàng)建設計良好但并不完美的軟件有一些概念，他還給出了一些這些年使用DDD的示例。

最早的DDD圖書的作者Evans指出，限界上下文的最初目的是讓我們認識到我們開發(fā)軟件的開發(fā)環(huán)境相當復雜，它涉及許多遺留系統(tǒng)和其他的外部系統(tǒng)，以及可能帶來影響的其他團隊。在圍繞軟件的一部分的上下文中，你擁有概念上的一致性，在此特定的詞總是意味著相同的事情。作為開發(fā)人員，你應該能夠識別出你是否處于上下文的邊界內(nèi)，然后需要遵循特定于該上下文的規(guī)則。邊界令你可以自由定義適用于那里的規(guī)則；不僅包括使用的術(shù)語，還包括架構(gòu)和開發(fā)過程。Evans指出，微服務應該是自治的，可以成為良好的限界上下文，但強調(diào)這一點并不意味著服務總是限界上下文，有時開發(fā)人員會把服務理解為限界上下文。

Evans認為康威定律（Conway's law）和限界上下文的概念之間存在一定的關聯(lián)，他想創(chuàng)立一些東西來應用該定律。他舉了一個例子，在一個系統(tǒng)中有兩個上下文：一個負責信用卡，另一個負責現(xiàn)金帳戶。這里我們在組織架構(gòu)、子域和限界上下文之間取得了協(xié)調(diào)一致。但是現(xiàn)在，為關注細分市場進行業(yè)務重組，將商業(yè)帳戶與個人帳戶分離，并為每種帳戶創(chuàng)建了一個團隊。兩個上下文保持不變（商業(yè)賬戶和個人賬戶都有信用卡和現(xiàn)金。譯者注），現(xiàn)在兩個團隊都在這兩個上下文中開展工作，時而發(fā)生的沖突意味著他們要協(xié)調(diào)他們的工作。他將這比喻為三足賽跑，為了提高速度，協(xié)調(diào)是必要的。在這種情況下，可能的風險是產(chǎn)生一個雜亂無章、隨意堆砌的系統(tǒng)(Big ball of mud)，Evans看到的一個常見原因是對軟件開發(fā)缺乏清晰的管理。一個可能的解決方案是建立一個新的邊界，使用防崩潰層（Anti-corruption layer）。

有時一個模型并不完備，不足以處理所要處理的所有情況。不是要創(chuàng)建一個能夠處理更多情況卻感覺很笨拙的模型，而是可以選擇創(chuàng)建一個函數(shù)來處理模型未能處理的情況。這樣的函數(shù)和許多if-then-else語句一起工作，和任何高層概念保持距離以避免創(chuàng)建另外一個模型。不應該使用不完備的或難以理解的抽象。Evans指出，最好使用if-then-else語句而不是錯誤地認為要創(chuàng)建一個優(yōu)雅的模型。創(chuàng)建這樣的模型可能最終連能工作的模型都找不到。他認為追求一個好的但并不完美的設計是關于權(quán)衡的很好的例子。

Evans不建議非得等到模型完美了才去使用它，那樣的話我們將無法發(fā)布任何軟件。我們必須忘掉這樣的想法，即只要你在前期投入額外的時間去做設計，從長期來看就一定能得到回報。然而，我們不能走向另一個極端，只是堆砌一些可怕的東西并發(fā)布出去。如果我們在模型中有意識地做一些權(quán)衡，并具備一定的技能，在對已有模型不滿意時知道該怎么做，將會得到更好的結(jié)果。

查看英文原文：Eric Evans: DDD is Not for Perfectionists