不要因為不知，所以設計

我們經常在設計的時候，會出現設計粒度的問題。這是乙個非常難以把握的。很多時候，我們處理這個問題的時候，會有來自不同方面的意見。認為再細的理由，一般來自擴充套件性。而來自稍微粗一點的理由，一般都是複雜度。

在最近的討論中，經常聽到的是關於擴充套件性的趨向。可是我們卻在慢慢地忘記了乙個根本問題：需求分析！

說乙個大家可能不愛聽的話。大部分系統分析工程師，都是從程式設計師轉過來的。因為大家不是專業的業務專家，所以對業務的把握能力在根本上就不是很好。面對這種情況，很多系統分析工程師在骨子裡有一種傾向：用更底層的抽象解決業務的擴充套件性。

這點雖然不是那麼容易說明，但確實是因為不知，所以設計。驗證這類設計的方式，就是問他們這樣設計的原因，他一開始很可能告訴你是因為擴充套件。你再問他，是因為甚麼擴充套件。如果他的回答不是很清晰的擴充套件，那麼很可惜，這裡的設計，很可能是因為「不知」而造成的。

程式設計師出生的系統分析工程師，對很多語言的框架有著很深的了解。事實上，這些都是他們成長的必要土壤，對框架他們有很深的情感。當在業務領域不能完全把握的時候，我們往往採取脫離業務的抽象方式，來逃避問題。

比如，我們經常說某個物件的屬性可能會變化。那好，我們就來個根本的設計：將物件轉換成徹底的類似資料庫記錄的形式：可以動態改變，可以進行配置。所有屬性的訪問，都是通過字元型的名稱來訪問。類似：fields["name"].asstring := "新的名稱"。

我並不反對資料化的設計，這些靈活性確實有很大的幫助。可是我們在作類似的設計的時候，經常性的問題就是，我們不知道那些物件，到底那些屬性是變化的，變化的原因是什麼，變化的影響是什麼。因為不知道，所以這些問題就不分析了。事實上，這些問題，可能到最後也得不到解決。

我一直傾向於基於分析而設計。對於乙個業務物件，我們只有把握住其根本的，才可能正確的把握設計的粒度。對於上面這個例子，我的建議是乙個折衷原則：業務物件一些根本的屬性，還是乙個業務物件，但是這乙個業務物件聚合乙個可擴充套件的資料物件。

不管怎麼樣設計，都是可取的。問題在於設計的背後，我們到底對於業務的把握度有多少。不了解或者不完全了解的情況下，設計出來的系統不能說有什麼嚴重後果。可是對於我們這些熱衷設計的人來說，是不可以原諒的。就如物件導向理念在我們心中，都已經成為乙個信念！

我曾經接觸過一些宣稱平台的系統，發現這些平台系統在業務處理上，也是屬於「不知」的情況下設計。這類平台，與其說是平台，還不如是框架，或者是架構平台的基礎框架。當我們寫出真正的平台的時候，我們是必須提供基礎的業務實體的，不管是基於物件模型，還是特定的平台業務模型。

總的一句話，愛好設計的我們，不能因為我們的無知，而設計出對未知的軟體出來。乙個笨辦法，好好理解業務！增加我們對業務的把握能力，對系統，對自己都是有非常好的幫助！