精品国产在线亚洲欧美-精品国产在线手机在线-精品国产在线国语视频-精品国产在线观看福利-亚洲色噜噜狠狠站欲八-亚洲色噜噜狠狠网站

首次上線應(yīng)用，面對業(yè)務(wù)框架搭建你是否曾感到無從下手？維護(hù)線上應(yīng)用，面對大量歷史包袱你是否正避坑不及深陷泥潭？為何同樣是業(yè)務(wù)應(yīng)用，不同人的設(shè)計風(fēng)格千差萬別？為何最初的設(shè)計經(jīng)過多個迭代后總是面目全非？新人來到團(tuán)隊，怎樣才能快速了解業(yè)務(wù)，不被大量技術(shù)細(xì)節(jié)折磨？如果你也有這些困擾，希望本文能提供些許幫助。

一 初衷

1 細(xì)節(jié)割裂架構(gòu)

業(yè)界的成熟應(yīng)用框架有很多。無論是SpringMVC/SpringBoot還是SofaBoot，都對工程結(jié)構(gòu)給出了明確的規(guī)范約定，職責(zé)邊界看似非常清晰。但在實(shí)踐中，再簡單的業(yè)務(wù)應(yīng)用都避免不了業(yè)務(wù)邏輯分散各處，打破module邊界出現(xiàn)隱式耦合的現(xiàn)象。分散的業(yè)務(wù)細(xì)節(jié)必然導(dǎo)致應(yīng)用架構(gòu)的割裂，如果沒有持續(xù)的重構(gòu)調(diào)整，最終總會變得復(fù)雜臃腫（當(dāng)然，是持續(xù)有新需求的前提下），老人沉默新人流淚，只能依靠天降猛男重做2.0。究其原因，個人認(rèn)為主要在于：

• 框架靈活性過高：應(yīng)用框架給出的是工程規(guī)范，而非業(yè)務(wù)設(shè)計規(guī)范，為開發(fā)者保留了非常大的靈活性，一個業(yè)務(wù)功能可以有很多種實(shí)現(xiàn)方式。
• 架構(gòu)約束力不足：業(yè)務(wù)架構(gòu)的搭建和維護(hù)是在不同時段由不同人分別投入的結(jié)果，設(shè)計思維的不同，自我要求的不同，項(xiàng)目進(jìn)度壓力的不同，都會對應(yīng)用的現(xiàn)狀產(chǎn)生影響。

若以法律和道德的關(guān)系做類比，通用框架約束了技術(shù)編碼的“法律”底線，而設(shè)計原則就是開發(fā)人員對自身的“道德”要求。在簡單的業(yè)務(wù)場景下，滿足需求是第一優(yōu)先級，設(shè)計能力的訴求并不突出。但在多方協(xié)作的業(yè)務(wù)團(tuán)隊下（真實(shí)情況大多如此），沒有統(tǒng)一的“道德標(biāo)準(zhǔn)”，將很難形成合力完成復(fù)雜項(xiàng)目。《Java開發(fā)手冊》（阿里巴巴Java開發(fā)規(guī)約）在推進(jìn)編碼標(biāo)準(zhǔn)的道路上邁出了很大一步，極大提升了工程人員的專業(yè)素質(zhì)，大大提高了“道德共識”。那么在業(yè)務(wù)架構(gòu)設(shè)計的領(lǐng)域里，是否至少能在某個問題域內(nèi)，也建立一套面向業(yè)務(wù)研發(fā)同學(xué)的“設(shè)計規(guī)約”。

2 技術(shù)沉淀流失

另一方面，進(jìn)入阿里巴巴后，自身研發(fā)經(jīng)歷雖然并不多，但接觸過不少優(yōu)秀設(shè)計。這些產(chǎn)出無論是否最優(yōu)方案，都體現(xiàn)出了技術(shù)同學(xué)對優(yōu)秀設(shè)計的美好愿望和強(qiáng)大落地能力，也確實(shí)在一定的歷史時期內(nèi)高效地保障了業(yè)務(wù)發(fā)展。然而，令我困惑的是，盡管每個業(yè)務(wù)項(xiàng)目和業(yè)務(wù)產(chǎn)品都能沉淀出一些可復(fù)用的組件或框架，參與研發(fā)的同學(xué)也能總結(jié)出一套面向未來需求的設(shè)計原則和實(shí)踐經(jīng)驗(yàn)，但這些財富始終難以維護(hù)和傳承。可能的原因有（對前端/測試/數(shù)據(jù)/平臺等研發(fā)經(jīng)歷不太了解，這里僅針對一線業(yè)務(wù)研發(fā)）：

• 堅持設(shè)計成果而非設(shè)計原則：有成功經(jīng)驗(yàn)的研發(fā)同學(xué)，傾向于用曾經(jīng)的架構(gòu)設(shè)計來套用當(dāng)下的業(yè)務(wù)場景。這種思路本身沒有對錯，但如果釘不配錘，往往會在短期內(nèi)引入大量額外成本，反倒喪失了原本的設(shè)計優(yōu)勢。面對具體問題域，只有堅持一貫的設(shè)計原則，在需求分析的過程中結(jié)合諸多因素進(jìn)行動態(tài)權(quán)衡，才能打造真正符合當(dāng)下和未來需求的設(shè)計。
• 喜歡造新輪子而非持續(xù)重構(gòu)：研發(fā)同學(xué)的設(shè)計原則和代碼潔癖可能是一種“玄學(xué)”，對前人代碼的不待見倒是更具確定性的常態(tài)，其實(shí)這不難理解。即使都是DDD流派，方案溝通時也未必互相認(rèn)可；即使經(jīng)過讓步對架構(gòu)設(shè)計達(dá)成一致，編碼實(shí)現(xiàn)的風(fēng)格也是各領(lǐng)風(fēng)騷。理解前人的設(shè)計思路和代碼癖好更重要，還是按時完成業(yè)務(wù)需求更重要？按自己擅長的設(shè)計風(fēng)格重寫更簡單，還是在他人的“過時”設(shè)計上持續(xù)重構(gòu)優(yōu)化更簡單？
• 靠文檔傳承而非工具化復(fù)用：對新人來說，文檔里的再多建議和快速上手指南，都比不上一個開箱即用的工程DEMO；在成熟應(yīng)用上持續(xù)開發(fā)的人，不會因?yàn)闅v史文檔上大寫的注意事項(xiàng)就抵抗住臨時代碼換取早點(diǎn)下班的現(xiàn)實(shí)誘惑，除非應(yīng)用工程中有編譯/部署失敗的強(qiáng)制約束讓你不得不放棄。

相比于缺少“設(shè)計規(guī)約”導(dǎo)致的低效協(xié)作，已經(jīng)沉淀的“規(guī)約原型”被輕易拋棄更加令人可惜。業(yè)務(wù)研發(fā)的日常工作，本質(zhì)上是拆解問題域的復(fù)雜性，用分層解耦/工具化/平臺化/業(yè)務(wù)抽象的多種思路將子問題逐個擊破。如果部分子問題已被很好解決，為何不站在前人肩上？放棄造不造新“輪子”的糾結(jié)心態(tài)吧，或許我們更需要搭“積木”的心態(tài)。

二 思路：業(yè)務(wù)架構(gòu)設(shè)計規(guī)約

結(jié)合螞蟻鏈-應(yīng)用技術(shù)團(tuán)隊近年來的技術(shù)實(shí)踐，我們試圖從自身需求出發(fā)，搭建一套或許能滿足更多業(yè)務(wù)場景的業(yè)務(wù)架構(gòu)設(shè)計規(guī)約。重點(diǎn)說明下，本文是從有限的問題域出發(fā)提出的解決思路，不奢求成為通用解決方案。如果其他業(yè)務(wù)線也有類似的痛點(diǎn)，希望能有些許借鑒。

• 標(biāo)準(zhǔn)：統(tǒng)一業(yè)務(wù)設(shè)計框架，用標(biāo)準(zhǔn)化架構(gòu)簡化技術(shù)細(xì)節(jié)
• 沉淀：從業(yè)務(wù)場景中持續(xù)沉淀“積木”
• 重構(gòu)：持續(xù)重構(gòu)“積木”，減少重復(fù)建設(shè)
• 集成：基于業(yè)務(wù)服務(wù)編排引擎快速集成

1 標(biāo)準(zhǔn)——減少細(xì)節(jié)

理想情況下，業(yè)務(wù)技術(shù)只需關(guān)注領(lǐng)域建模，但現(xiàn)實(shí)中卻不得不考慮更多通用的技術(shù)細(xì)節(jié)。以供應(yīng)鏈金融場景下簡化版的應(yīng)收賬款發(fā)行流程為例，需要考慮的有：

• 領(lǐng)域建模：應(yīng)收賬款領(lǐng)域模型及其行為的設(shè)計
• 流程編排：流程模型的設(shè)計及發(fā)行流程的狀態(tài)機(jī)設(shè)計
• 數(shù)據(jù)轉(zhuǎn)換：領(lǐng)域模型<->數(shù)據(jù)模型及流程模型<->數(shù)據(jù)模型的雙向轉(zhuǎn)換
• 并發(fā)控制：業(yè)務(wù)鎖機(jī)制的設(shè)計
• 業(yè)務(wù)冪等：流程中各業(yè)務(wù)環(huán)節(jié)的冪等控制
• 異常處理：異常捕捉，錯誤碼約定
• 監(jiān)控報警：摘要日志，異常日志，邊界日志
• 其他

在以上未完全列舉的幾項(xiàng)中，除了“領(lǐng)域建模”以外，基本都是與具體業(yè)務(wù)無關(guān)，但對于一個穩(wěn)定可靠的業(yè)務(wù)應(yīng)用不可缺失的部分。如果能建立一套標(biāo)準(zhǔn)化的框架方案，用統(tǒng)一的規(guī)范解決掉業(yè)務(wù)無關(guān)的大量細(xì)節(jié)，是否就能讓業(yè)務(wù)技術(shù)同學(xué)真正的專注于“領(lǐng)域建模”？

2 沉淀——能力復(fù)用

沉淀和復(fù)用是技術(shù)群最常出圈的幾個詞，可見認(rèn)同度之高。能力復(fù)用不局限于形式和粒度，能夠切實(shí)降低技術(shù)成本，提高業(yè)務(wù)擴(kuò)展性，就是不錯的沉淀，可作為“積木”供后續(xù)使用。以螞蟻鏈應(yīng)用技術(shù)團(tuán)隊場景為例，近年來沉淀的能力包括但不局限于：

技術(shù)類

• 工程規(guī)范系列：約束編碼規(guī)范和邊界接口定義風(fēng)格，日志打印，異常處理，倉儲行為，狀態(tài)機(jī)等等
• 讀寫分離機(jī)制：屏蔽交易類需求與查詢類需求對數(shù)據(jù)模型的設(shè)計沖突，降低設(shè)計復(fù)雜性，提升查詢性能和靈活性

業(yè)務(wù)類

• 網(wǎng)銀核身：提高網(wǎng)銀核身簽名在不同業(yè)務(wù)流程中的擴(kuò)展性
• 合約上鏈：提高智能合約對接在不同業(yè)務(wù)流程中的擴(kuò)展性

平臺類

• 配置中心：靈活定義和管理業(yè)務(wù)流程需要的各類配置項(xiàng)
• 產(chǎn)品中心：平臺功能打包和隔離，實(shí)現(xiàn)業(yè)務(wù)流程的全局視圖

3 重構(gòu)——持續(xù)優(yōu)化

沉淀來源于業(yè)務(wù)需求，卻常常落后于新需求。對于設(shè)計者以外的人來說，維護(hù)他人的“積木”常常會踩到不少坑，反倒不如自己重寫。這也是為何每個團(tuán)隊都在說沉淀，但能夠橫向復(fù)用，甚至在同一個團(tuán)隊內(nèi)持續(xù)復(fù)用的能力都少之又少。雖然這個現(xiàn)象沒有完美解法，但個人建議采取以積極的心態(tài)看待這些“積木”：

• 分析歷史背景，了解“積木”出現(xiàn)的技術(shù)和業(yè)務(wù)背景
• 明確該能力能夠解決的問題，和不適用的場景
• 分析當(dāng)下業(yè)務(wù)需求，是否可以重構(gòu)該能力后直接復(fù)用
• 與創(chuàng)作者溝通，評估重構(gòu)落地方案

這里沒有強(qiáng)調(diào)重構(gòu)復(fù)用和重寫這兩種方案的ROI對比，是因?yàn)閭€人看來，即使前者成本更高，重構(gòu)的過程對個人技術(shù)成長和團(tuán)隊文化統(tǒng)一都是有利的。相對于不斷推翻和發(fā)明新“積木”，持續(xù)優(yōu)化的過程，是對自己和他人經(jīng)驗(yàn)的不斷回顧和反思，看清歷史的坑，才能避免新風(fēng)險的出現(xiàn)。

4 集成——靈活搭建

標(biāo)準(zhǔn)能夠落地，除了有足夠趁手的“積木”庫外，更重要的一點(diǎn)，是要有靈活便捷的“粘合劑”，以完成業(yè)務(wù)功能的快速搭建和靈活調(diào)整。在供應(yīng)鏈金融的場景下，業(yè)務(wù)需求主要體現(xiàn)為各種各樣的業(yè)務(wù)流程，比如發(fā)行/轉(zhuǎn)讓/清分等等。為了簡化“積木”搭建，靈活復(fù)用底層能力，我們基于以下目標(biāo)，設(shè)計了面向業(yè)務(wù)的服務(wù)編排引擎：

• 標(biāo)準(zhǔn)化：遵循設(shè)計規(guī)約，將業(yè)務(wù)無關(guān)的通用技術(shù)細(xì)節(jié)屏蔽
• 插件化：對“積木”友好，可持續(xù)沉淀和復(fù)用新能力
• 業(yè)務(wù)化：面向業(yè)務(wù)，有業(yè)務(wù)描述能力的流程編排
• 配置化：通過配置即可完成流程編排，最好能做到可視化配置

5 產(chǎn)品——業(yè)務(wù)大圖

“積木”+“粘合”能夠滿足技術(shù)落地的低成本高擴(kuò)展，但從業(yè)務(wù)視角，還需要一個全局大圖來描繪業(yè)務(wù)線的全域能力和功能流程。本文中暫不涉及。

三 實(shí)踐——業(yè)務(wù)架構(gòu)標(biāo)準(zhǔn)方案

如前所說，只靠文檔形成的共識，對技術(shù)沒有足夠的約束，極難維持。因此，我們基于上述規(guī)約的各項(xiàng)原則，搭建了一套標(biāo)準(zhǔn)化的業(yè)務(wù)架構(gòu)設(shè)計方案，通過組件化工具化的方式約束業(yè)務(wù)應(yīng)用，形成團(tuán)隊共識。一個標(biāo)準(zhǔn)的業(yè)務(wù)應(yīng)用架構(gòu)如下：

1 組件——規(guī)范技術(shù)細(xì)節(jié)

通過組件化約定，約束通用技術(shù)細(xì)節(jié)的行為，包括但不局限于：

交易模型

描述業(yè)務(wù)流程的核心交易模型，用于管控狀態(tài)推進(jìn)，維持與業(yè)務(wù)模型的關(guān)聯(lián)。

倉儲行為

數(shù)據(jù)持久層的通用行為，包括鎖定查詢/插入/更新/普通查詢等。

事務(wù)模板

定義事務(wù)邊界，確保模版內(nèi)業(yè)務(wù)邏輯的事務(wù)一致性；支持冪等能力。

通用業(yè)務(wù)模板

定義業(yè)務(wù)邏輯邊界，無事務(wù)性保障，但包含了異常處理/日志埋點(diǎn)等通用能力。

通用查詢模板

定義查詢邏輯邊界，與通用業(yè)務(wù)模板類似，但主要面向單項(xiàng)/批量/分頁等查詢場景。

消息

對消息中間件的簡單封裝，適配業(yè)務(wù)應(yīng)用規(guī)約，降低配置成本。

調(diào)度

對調(diào)度中間件的簡單封裝，適配業(yè)務(wù)應(yīng)用規(guī)約，降低配置成本。

服務(wù)開放

api組件規(guī)范對外服務(wù)能力，通過注解識別服務(wù)定義和服務(wù)實(shí)現(xiàn)，自動生成接口文檔，描述接口參數(shù)/返回/業(yè)務(wù)域/錯誤碼等等。

其他——日志/異常處理/請求參數(shù)/返回類型

這里不做展開。

以上是所有業(yè)務(wù)應(yīng)用都會遇到的技術(shù)細(xì)節(jié)，用組件屏蔽細(xì)節(jié)的思路也沒有復(fù)雜之處，我們想要表達(dá)的重點(diǎn)是：盡可能沉淀和復(fù)用技術(shù)組件，盡可能使用他人的成果，不要重復(fù)搭建，把重心放到業(yè)務(wù)上！

2 領(lǐng)域——專注業(yè)務(wù)建模

再次強(qiáng)調(diào)，對業(yè)務(wù)技術(shù)來說，業(yè)務(wù)建模是核心，業(yè)務(wù)建模是核心，業(yè)務(wù)建模是核心！本文的初衷和方案都是為了讓開發(fā)解放出來，直面核心業(yè)務(wù)的設(shè)計和思考。本小節(jié)僅給出領(lǐng)域產(chǎn)出的基本要求，后續(xù)在【案例分析】再做詳述。

領(lǐng)域?qū)嶓w

建模的核心是抽象出領(lǐng)域?qū)嶓w及其關(guān)聯(lián)關(guān)系，不同的業(yè)務(wù)場景和設(shè)計思路，會有很大差異，最終會體現(xiàn)為一到多個領(lǐng)域模型。需要明確在不同業(yè)務(wù)流程下，各交易模型內(nèi)需要包含的領(lǐng)域模型（比較抽象，后續(xù)在【案例分析】再做詳述）。

領(lǐng)域倉儲

定義數(shù)據(jù)模型，及其與領(lǐng)域模型的對應(yīng)關(guān)系（各種converter）。基于上文提到的倉儲組件，配置數(shù)據(jù)庫表和連接，實(shí)現(xiàn)鎖定查詢/插入/更新/普通查詢等業(yè)務(wù)行為。

領(lǐng)域服務(wù)

基于業(yè)務(wù)行為，抽象出原子化的領(lǐng)域服務(wù)能力。該服務(wù)無需關(guān)注數(shù)據(jù)倉儲，無需關(guān)注業(yè)務(wù)流程，僅抽象出領(lǐng)域?qū)嶓w的原生能力。以上文中提到的應(yīng)收賬款模型為例，至少需要包含：

• 應(yīng)收賬款的創(chuàng)建
• 應(yīng)收賬款的拆分/流轉(zhuǎn)
• 應(yīng)收賬款的銷毀

等等基本行為。

交易實(shí)體

用于承載交易流程的業(yè)務(wù)實(shí)體，上文中交易模型的業(yè)務(wù)實(shí)例，內(nèi)部關(guān)聯(lián)一到多個領(lǐng)域?qū)嶓w。

交易倉儲

用于管控交易實(shí)體以及內(nèi)部各領(lǐng)域?qū)嶓w的倉儲行為。

3 服務(wù)編排引擎 —— 積木+粘合

但凡涉及復(fù)雜業(yè)務(wù)流程的應(yīng)用，都需要引入流程引擎來編排狀態(tài)機(jī)的流轉(zhuǎn)。業(yè)界有很多成熟的流程引擎框架，也有很多足夠可用的簡化版本。但如前文所說，這類通用引擎的優(yōu)點(diǎn)也是其最大的弱點(diǎn)：過強(qiáng)的靈活性無法對設(shè)計風(fēng)格形成約束，大量業(yè)務(wù)細(xì)節(jié)會分散在不同狀態(tài)節(jié)點(diǎn)間，不直觀也難維護(hù)。從自身需求出發(fā)，我們設(shè)計了面向業(yè)務(wù)的服務(wù)編排引擎，以遵循業(yè)務(wù)設(shè)計規(guī)約的方式約束技術(shù)，以直觀的形式描述業(yè)務(wù)流程。與傳統(tǒng)流程引擎相比，其業(yè)務(wù)友好性主要體現(xiàn)在：

• 約束業(yè)務(wù)模型：需明確指定業(yè)務(wù)交易模型/狀態(tài)及倉儲定義，遵循業(yè)務(wù)設(shè)計規(guī)范
• 托管倉儲行為：只需配置業(yè)務(wù)模型及倉儲實(shí)現(xiàn)，無需再關(guān)注數(shù)據(jù)持久化的時機(jī)和細(xì)節(jié)
• 編排領(lǐng)域服務(wù)：通過轉(zhuǎn)接層，將領(lǐng)域服務(wù)開放到引擎中自由編排。領(lǐng)域的原子能力是引擎編排的最小執(zhí)行單位
• 靈活增減狀態(tài)：流程中的狀態(tài)遷轉(zhuǎn)和業(yè)務(wù)行為均可被靈活插拔
• 支持“積木”擴(kuò)展：將可復(fù)用的領(lǐng)域服務(wù)組合打包，形成固定模式，作為“積木”在其他流程中重復(fù)使用

總的來說，服務(wù)編排引擎基于通用組件屏蔽技術(shù)細(xì)節(jié)，重點(diǎn)專注于業(yè)務(wù)行為的編排和復(fù)用，對“積木”進(jìn)行“粘合”，以編排出符合業(yè)務(wù)需求的業(yè)務(wù)流程。

四 總結(jié)

本文從業(yè)務(wù)技術(shù)團(tuán)隊的現(xiàn)實(shí)痛點(diǎn)出發(fā)，嘗試以業(yè)務(wù)架構(gòu)設(shè)計規(guī)約（理論標(biāo)準(zhǔn)）結(jié)合業(yè)務(wù)架構(gòu)標(biāo)準(zhǔn)方案（工程約束）的思路統(tǒng)一團(tuán)隊的技術(shù)風(fēng)格，將技術(shù)同學(xué)從細(xì)節(jié)中釋放出來，專注于技術(shù)能力的積累和對業(yè)務(wù)價值的思考。希望傳達(dá)的想法有：

• 用標(biāo)準(zhǔn)約束技術(shù)細(xì)節(jié)：降低業(yè)務(wù)設(shè)計的靈活性，也是為了減少成本
• 用技術(shù)工具而非文檔推行標(biāo)準(zhǔn)：持續(xù)沉淀的組件，勝過沒有約束力的文檔
• 持續(xù)重構(gòu)而非造新輪子：正視自己和他人曾經(jīng)的產(chǎn)出，持續(xù)改進(jìn)能帶來成長
• 重視業(yè)務(wù)建模：好好思考業(yè)務(wù)和行業(yè)吧，用DDD武裝自己，提升建模思維和能力

宏思銳達(dá)是專業(yè)貴陽APP開發(fā)公司，擁有專業(yè)的本地項(xiàng)目團(tuán)隊，歡迎您咨詢貴州宏思銳達(dá)！