模板與例項在系統中的應用
模板是什麼
模板定義了通用的結構和行為，包含了一系列方法和屬性，這些方法和屬性為系統提供了參考。
例項是什麼
例項是模板的具體實現，繼承了模板的結構和行為，併為模板中的抽象和屬性提供了實現。
模板是定義系統有什麼功能，例項就是這些功能的具體實現。在系統設計上，如何識別出產品描述的需要什麼功能和如何實現功能這點上，如果有理論支撐，將規避不少系統設計的坑。
例如
產品需要設計一個會員系統，使用者在系統下單購買了年卡商品就會開通會員。
需求如何轉化成系統設計
我們需要設計一個後端操作介面，讓運營能夠配置對應的年卡商品。
使用者在下單時，訂單裡有年卡商品，就要給使用者生成一個會員。
在這個描述中，運營建立的每一條記錄為模板，使用者按模板生成的每一條記錄為例項。
那麼開通會員是我們的例項，而建立例項需要使用者下單購買了年卡商品，那麼購買動作是發起建立例項的開始，購買年卡商品是建立例項的條件
後續，如果會員系統要指定使用者購買指定商品就開通會員。
那麼模板上就是指定使用者和指定商品。
例項化會員的時候，判斷條件就多了指定使用者和指定商品的判斷。
總結出4個要素
-
模板
-
例項
-
動作
-
條件
線下門店做會員日活動，要求每個門店能夠自主決定做會員日的日期和選擇什麼樣的禮品，系統怎麼設計？
例項：會員日活動
條件：選擇日期、選擇禮品
動作：門店建立
模板：日期選擇區間，可供選擇的禮品列表
這幾個條件就能設計出一個系統雛形，現實場景中，功能特別多，當功能多了以後，就會有各種分類、組合等組成一個龐大且複雜的系統。
對於這種功能越來越多，組合方式也越來越多的情況，類似於設計模式中的factory，建立複雜例項不是簡單的new出來，而是需要各種資料協調，有些例項建立只需要簡單幾個引數，有得需要藉助其他平臺的資料才能完成。對於使用者來說，不需關心繫統是如何建立的，只需要關心自己關心的業務即可。
當業務再複雜點，還是每個門店能自主建立會員日活動，但每個會員日活動又不一樣。比如有些需要送禮品，有些不需要送禮品，這時候的解法如下。
例項：會員日活動
條件：選擇日期、選擇禮品
動作：門店建立
模板：日期選擇區間，活動A可選禮品，活動B不可選禮品
來到這一步，就發現，業務變化的條件不是建立例項上，而是建立例項的源頭，模板的變化導致例項化也要跟著變，那麼我們的解決辦法是什麼了，參考抽象工廠模式。
首先，工廠模式是模板+資料生成例項，那麼抽象工廠模式就是不同條件的模板 + 資料生成不同型別例項。關鍵點是要生成功能相似物件，只是抽象工廠多了變數，建立者本身是不同型別的，在建立工廠時，需要將變數作為條件。
模板與例項是一種建立型設計，是設計模式中的工廠模式，業務的變化無限，但設計有限。將業務語言翻譯成系統語言，一套成熟的方法論能保證系統非常強大且容易維護。
這套理論，延展到領域模型、資料表設計、程式碼實現也同樣適用。