前言
去年11月從之前的業務部門調動到業務平臺之後，團隊的重心與目標都發生了不少的變化，之前的團隊主要服務一個業務方，業務的目標相對比較重要，對於技術人員的業務sense，產品sense要求比較高，會要求從業務發展與規劃方面入手對技術進行佈局；而業務平臺是服務整個集團的所有業務，屬於比較底層的平臺，對業務的KPI感知不是特別明顯，而對於平臺的穩定性與擴展性要求比較高，需要平臺能沉澱出可複用的能力，同時可以方便靈活的定製，甚至能開放給業務團隊自助開發，對於技術的應用架構也提出更高的要求。
目標
《架構整潔之道》中定義應該架構的目標：減少資源的投入。其中，資源的投入包括整個研發的流程，需求的評估、設計、開發、測試、上線、維護等。對於平臺來說，這個目標非常合適，面對諸多業務方，不斷新增的需求，能夠減少資源投入甚至無需投入（業務自助）才能更好的支持業務發展。而對於具體的業務方來說，上線的時間是最重要的，而往往一些新的業務的訴求比較特別，平臺能力無法直接滿足，這個時候爲了快速上線往往使用一些臨時方案。作爲業務平臺，既要能提供插件式的功能也要支持功能的沉澱，類似操作系統能夠支持軟件的按照又要定期的升級系統提供新的功能。
方法論
爲了實現功能的複用，讓應用可以類似積木一樣搭建起來，需要做的兩方面，第一是減少功能的外部依賴，保留功能的業務核心邏輯；第二是保證功能的原子性。
其中第一點也保證了功能的擴展性，例如一個翻譯功能，核心邏輯在於翻譯，而不在於文本的輸入輸出，保留核心可以讓功能在標準輸入上使用也可以作爲服務進行封裝。例如下圖
當面對業務訴求時，先停下來思考下應用的每一層應該如何劃分，尤其是領域規則與應用業務規則之間。上圖的右下角部分說明了層之間的交互，其實就是依賴倒置。
而第二點涉及到靈活性與便捷性的權衡。如果提供的功能粒度太粗，複用起來比較方面，但是不利於擴展。如果提供的功能粒度太細，剛好相反。功能粒度可以通過不同的層級來提供，領域規則提供原子能力，業務規則提供通用複用能力。
功能的複用主要是利於減少開發與維護等環節的資源投入，而對於需求，設計等可以通過可視化的方式將應用的功能展示出來，這樣很好解決評估需求的資源投入以及人員變動帶來的風險。
其它
本文只是一個應用架構的粗略思考，後續會對應用架構的步驟進行分開總結，方便後續實踐過程中的落地與反饋。