如何從企業應用程序的類設計開始？

Question

如何在開始開發大型應用程序（包括WinForm和WebApp）之前從類設計入手。在設計課程結構之前，我應該檢查什麼是最初的「小心」事情？

如何識別我的應用程序設計中的接口，抽象類，委託，事件等的用法？

Answer 1

徹底解答這個問題需要一本書，而不是StackOverflow文章！事實上，已經有不少書籍，像Martin Fowler的Patterns of Enterprise Application Architecture。以下是一些常用指針：

• 確保您瞭解您正在處理的問題域的部分。你有沒有和你的顧客談過，先讓他們處理事情？你的領域模型是否符合他們對世界的看法？

• 統計學上講，你的應用程序不太可能是特殊的。這意味着如果有人堅持認爲他們需要特定的體系結構或實現模式（例如企業服務總線，消息隊列等），則應該持懷疑態度的眼光來看待它。考慮另一種方法可能不會更好。

• 在結構上和邏輯上將應用程序的不相關部分彼此隔離。不要鬆散地耦合或分離你的課程;使他們完全獨立的項目必須單獨建立。

• 代碼接口，而不是實現。如果許多類都做類似的事情，那就製作一個界面。不要使用抽象基類作爲僞接口。取決於接口並傳遞該接口而不是各個實現類。

• 瞭解更大範圍的應用程序。它提供什麼商業目的？它將如何幫助人們，實現目標或提高生產力？你正在建立的東西是否與此目的一致？確保你不是爲了建築而建造的。

• 當有人告訴你這是一個「企業應用程序」時要小心。對於太多不同的人來說，這是一個內容太多的詞。確保清楚交叉問題，如安全，授權，認證，服務保證等。

• 企業應用程序容易膨脹。不要害怕對新功能說「不」，並且用單元測試進行無情重構，以確保您獲得最大的回報。

• 最後，一切都適中。將上述任何一種（或者一般來說，真的）都變爲極端是一個壞主意。你真正應該做的唯一事情就是適度本身！ :)

Answer 2

我看到兩種基本類型的設計活動。

主要系統碎片有分解。所以你已經有了一些想法，從系統的其他部分分離出來。你可能也會有一些業務邏輯和持久性。第一個重要問題是，您真正擁有多少業務邏輯。有些系統在簡單數據庫之前不過是一個簡單的皮膚，幾乎沒有任何真正的業務邏輯。其他人有非常重要的業務邏輯部分，這在某種程度上是獨立的。

如果您有主要的半獨立部分，他們可能最好通過事件和消息隊列進行通信。因此，請確定您是否有需要這種解耦關係的部分，並導致識別這些事件的事件和有效負載。這是另一個答案中引用的福勒變得相關的地方。

接下來鑽入業務邏輯部分。接口和抽象類等是構造複雜性實現的技術。分開您的代碼，以便隱藏細節並啓用靈活性。我認爲這是一個面向對象的設計練習，有很多關於這方面的書籍，例如head first。

Answer 3

爲了給您一個很大的問題的簡短答案 - 不要先從班級設計開始。從組件，層的設計開始，做出一些技術決策，例如「我需要一個數據庫，如果是，哪一個」。這假設你已經完成了對問題域的一些分析，發現了一些基本的用例等。

當你準備好了，編寫一個「切入」應用程序來驗證你的架構決定。這意味着，一個小應用程序觸及大部分圖層，而只處理一個非常小的用例。它應該足夠小，以便在您認爲您的架構的某些部分存在缺陷時可以輕鬆地進行重寫/糾正/丟棄。這也是一種很好的技巧，可以幫助您掌握課堂設計。