在Java生鮮電商平臺中，微服務(wù)體系的分層設(shè)計與領(lǐng)域劃分應(yīng)該怎么樣呢？

看標(biāo)題感覺這個東西很理論，比起“高并發(fā)、多線程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具體的干貨技術(shù)點，軟件體系知識顯得很“濕”，似乎人人都有自己的認(rèn)識，但又很少有人能說完整，有一點可以確定的是，如果你未來需要獨立設(shè)計一個復(fù)雜的系統(tǒng)中臺，并使之未來能快速應(yīng)對各種需求變化的話，科學(xué)合理的領(lǐng)域劃分和邊界界定需要我們“處女座級”的堅持下去，這對防止人力失控、減少項目爛尾很有幫助。合理的界定了邊界后，即便某個微服務(wù)很糟糕，也可以就輸入輸出以很少的人力投入進行重構(gòu)，相反的就是牽一發(fā)而動全身，加上業(yè)務(wù)需求頻繁而來，很容易爛尾或是達不到如期的效果。

其實很多技術(shù)大神都是某一個技術(shù)點的好手，但可能在整體軟件體系上思考并不多，每個人都有自己的設(shè)計方法，大部分容易想到的設(shè)計方法處理一般的系統(tǒng)已經(jīng)夠了，后面發(fā)生問題慢慢打補丁就行了，當(dāng)我們面對各種需求變化陷入開發(fā)困境的時候我們就該想想了，咱們系統(tǒng)的體系設(shè)計上是否出了問題？本文不打算涉及領(lǐng)域建模和設(shè)計模式等代碼級別的詳述，而是探討如何將一個復(fù)雜的大系統(tǒng)進行分層和拆分，這是設(shè)計一個優(yōu)美系統(tǒng)的第一步，相信對各BU同事們快速搭建系統(tǒng)中臺也是很有參考意義的。

文中的一些例子大家也可能遇到過，大家如果在開發(fā)中遇到困境，可以多來圈子交流和發(fā)表問題，大家一起學(xué)習(xí)進步。大概知道內(nèi)容背景的可以直接跳到第3部分。想了解一個大項目如何進行科學(xué)人員安排的可以直接看5.4部分。如果你的組里還有人把數(shù)據(jù)庫模型當(dāng)接口契約用，可以建議他看下5.1部分。假如你在開發(fā)過程中遇到一些別人的開發(fā)設(shè)計習(xí)慣，你覺得不是很好，但是又不知道如何說服他，都可以到評論區(qū)聊聊，大家一起討論討論。

1.摘要

本文闡述了一種將分層設(shè)計和DDD領(lǐng)域設(shè)計思想應(yīng)用于微服務(wù)體系架構(gòu)的方案實踐，也是個人的最佳實踐。

對于大部分互聯(lián)網(wǎng)公司來說，我們主張將其Web服務(wù)架構(gòu)分為五層：基礎(chǔ)設(shè)施層、領(lǐng)域服務(wù)層、應(yīng)用服務(wù)層、網(wǎng)關(guān)層和用戶界面層（表示層）。領(lǐng)域服務(wù)層和應(yīng)用服務(wù)層均可以采用微服務(wù)設(shè)計進行拆分，其中領(lǐng)域服務(wù)層將按照DDD領(lǐng)域設(shè)計進行領(lǐng)域劃分，設(shè)計為一個個領(lǐng)域模塊微服務(wù)，每個微服務(wù)高度內(nèi)聚，僅關(guān)注自己的業(yè)務(wù)，領(lǐng)域服務(wù)間通過接口調(diào)用進行松耦合。這種設(shè)計方案可以大大簡化大系統(tǒng)，并且在后期的維護中優(yōu)勢會日漸凸顯，然而把大系統(tǒng)分而治之拆成微服務(wù)同時也對架構(gòu)師和開發(fā)人員提出了更高的要求。

第2部分介紹了相關(guān)背景，接著第3部分探討了分層設(shè)計以及每一層的功能，第4部分結(jié)合微服務(wù)和DDD對領(lǐng)域服務(wù)層進行服務(wù)模塊劃分和設(shè)計。第5部分則就分層設(shè)計和DDD領(lǐng)域設(shè)計中常見的問題進行了整理。

2.背景介紹

想寫這樣一篇文章很久了，雖然本科學(xué)的是軟件工程，但礙于自己能力有限，從08年寫代碼以來一直斷斷續(xù)續(xù)的思考，始終對項目模塊設(shè)計和分層結(jié)構(gòu)設(shè)計沒有一個可以讓自己覺得滿意且無糾結(jié)點的答案，假設(shè)了某個設(shè)計，很快在實踐中又會發(fā)現(xiàn)其存在著一些問題。直到2014年畢業(yè)工作了解了DDD領(lǐng)域驅(qū)動設(shè)計后，才有了相對清晰的方向。

實際上早在2004年，Eric Envas的《領(lǐng)域驅(qū)動設(shè)計：軟件核心復(fù)雜性應(yīng)對之道》就已出版，畢竟軟件開發(fā)自計算機普及以來已經(jīng)存在很長一段時間了，早期國外程序員對軟件開發(fā)理論的研究也十分興盛，如今成熟后反而研究的相對少了，基本上依葫蘆畫瓢即可。

DDD領(lǐng)域驅(qū)動設(shè)計對軟件設(shè)計各個環(huán)節(jié)的人員都有較高的要求,用《領(lǐng)域驅(qū)動設(shè)計》一書的話來說它需要一個“領(lǐng)域驅(qū)動團隊”[1]，它要求從分析階段，產(chǎn)品經(jīng)理、項目經(jīng)理、架構(gòu)師以及開發(fā)工程師就使用統(tǒng)一的模型語言（Ubiquitous Language）來進行溝通，并且他們都懂一些代碼、產(chǎn)品和建模相關(guān)的知識，事實上這在國內(nèi)很難實施，國內(nèi)的產(chǎn)品經(jīng)理約等于需求整理工，對其計算機基礎(chǔ)的要求是少之又少，在我所從事的公司里，也曾發(fā)生過產(chǎn)品經(jīng)理直接指導(dǎo)開發(fā)，以至于后面雙方理解的同一個詞有著不同含義的情況。

所以本文不打算去闡述DDD領(lǐng)域內(nèi)部建模代碼級別的實踐，甚至本文并不認(rèn)為貧血模型是不好的，本文主要探討領(lǐng)域之間的劃分和分層設(shè)計，正如引言說提到的，這是設(shè)計優(yōu)美系統(tǒng)的第一步。另外提一句：其實合理設(shè)計的微服務(wù)體系中的服務(wù)本身就是功能單一邊界清晰的小應(yīng)用，屆時貧血也好、DDD領(lǐng)域建模也好，其實都可以勝任。

近年來，隨著分布式的發(fā)展，傳統(tǒng)中小型機集中式服務(wù)器已經(jīng)不在流行，所以微服務(wù)體系也成為了各大互聯(lián)網(wǎng)公司主流的選擇。直觀的感受下微服務(wù)和DDD兩者，似乎一個是微系統(tǒng)，另一個則是大系統(tǒng)的設(shè)計方法，似乎兩者天生互斥，微服務(wù)化的小系統(tǒng)也用不著DDD，其實并不是，DDD是針對整個復(fù)雜的軟件解決方案的一種科學(xué)設(shè)計方法，微服務(wù)化也是把復(fù)雜的大系統(tǒng)拆分為小系統(tǒng)，方便維護和管理，所以兩者都有一個特點——為復(fù)雜的大系統(tǒng)服務(wù)。

下面咱們就來探討下，如何把DDD的領(lǐng)域設(shè)計和其主張的分層設(shè)計應(yīng)用到微服務(wù)體系架構(gòu)中。需要說明的是本文主要是個人多年來的一點總結(jié)，未必適合所有場景，有更好通用性更為廣泛的方案請不吝賜教。

3.分層設(shè)計

準(zhǔn)確的說分層設(shè)計（Layered Architecture）跟DDD沒有必然的聯(lián)系，我最早接觸分層設(shè)計是在攜程網(wǎng)，當(dāng)時內(nèi)部使用的應(yīng)該只是簡單的業(yè)務(wù)層（Biz）和表示層，數(shù)據(jù)庫訪問之類的也是放在各自的業(yè)務(wù)包下的。后來接觸和學(xué)習(xí)了《領(lǐng)域驅(qū)動設(shè)計：軟件核心復(fù)雜性應(yīng)對之道》，書的第4章“分離領(lǐng)域”中說到了四層分層設(shè)計，即：基礎(chǔ)設(shè)施層、領(lǐng)域?qū)?、?yīng)用層和用戶界面層（表示層）。DDD產(chǎn)生的年代微服務(wù)還未流行，當(dāng)時甚至基于瀏覽器的Web應(yīng)用都比較少，更多的是PC軟件和EJB等網(wǎng)絡(luò)應(yīng)用，所以作者更多的是想表達對復(fù)雜系統(tǒng)的邏輯分層，并不在意每個領(lǐng)域是單獨的系統(tǒng)還是一個軟件系統(tǒng)內(nèi)不同的模塊。

所以為了跟其做區(qū)分，我們建議的四層為在其基礎(chǔ)上引入“服務(wù)”兩個字，即：基礎(chǔ)設(shè)施層、領(lǐng)域服務(wù)層、應(yīng)用服務(wù)層和用戶界面層。這樣做的意圖是讓開發(fā)人員立刻可以了解到——每個領(lǐng)域模塊即一個微服務(wù)（一個領(lǐng)域可以對應(yīng)一個或者多個模塊Module）。摘要中提到我們主張的分層體系中還有一個層，即網(wǎng)關(guān)層，這又是什么鬼呢。

剛剛提到的DDD的時代背景，PC軟件系統(tǒng)或者企業(yè)內(nèi)部使用的網(wǎng)絡(luò)應(yīng)用系統(tǒng)是根本沒有網(wǎng)關(guān)層（有也是網(wǎng)絡(luò)網(wǎng)關(guān)設(shè)備）這一說的，而現(xiàn)如今互聯(lián)網(wǎng)公司產(chǎn)品的輸出形式無外乎Web應(yīng)用（網(wǎng)站、或者網(wǎng)絡(luò)服務(wù)），并且為了更好的適配PC站和App，一般會采用前后端分離的應(yīng)用設(shè)計方案，這時候會產(chǎn)生一個需求——內(nèi)部網(wǎng)絡(luò)應(yīng)用系統(tǒng)如何把自己的服務(wù)輸出到互聯(lián)網(wǎng)上，供外部系統(tǒng)或者瀏覽器網(wǎng)頁訪問。最直接的方式就是把應(yīng)用層直接暴露在公網(wǎng)上，但我們不建議這么做，應(yīng)用層服務(wù)更多的是關(guān)注業(yè)務(wù)應(yīng)用，對網(wǎng)絡(luò)級的系統(tǒng)安全性（防DDOS、釣魚、跨域等）、請求監(jiān)控等缺乏考慮，這些工作交給網(wǎng)關(guān)層統(tǒng)一管理會輕松很多（比如淘寶的TOP平臺）。

這時候我們在Web應(yīng)用系統(tǒng)中引入網(wǎng)關(guān)層用于銜接表示層和應(yīng)用層 ，因為這樣可以更好的劃分各層的職能。網(wǎng)關(guān)層也可以看作是應(yīng)用服務(wù)層的對外包裝層。如果一定要把網(wǎng)關(guān)層做到應(yīng)用服務(wù)層里理論上也是可行的，比如針對于Spring Cloud這種框架下的微服務(wù)體系，可以考慮直接暴露應(yīng)用層，只需輔助一些運維手段進行統(tǒng)一的安全驗證和監(jiān)控即可。

假設(shè)我們選擇引入網(wǎng)關(guān)層，那么我們就得到了以下網(wǎng)絡(luò)應(yīng)用系統(tǒng)分層體系：

其中，各層的職能和作用為[2]：

用戶界面層：負責(zé)向用戶顯示和解釋用戶指令。這里指的用戶可以是另一個計算機系統(tǒng)，不一定是使用用戶界面的人（比如外部應(yīng)用調(diào)用對應(yīng)接口）。前后端分離時，該層可以扮演前端所需數(shù)據(jù)的組裝者。

網(wǎng)關(guān)層：負責(zé)提供對外的HTTP服務(wù)或者其他應(yīng)用層協(xié)議（這里是指OSI七層協(xié)議中的應(yīng)用層，別混淆了哈）服務(wù)。

應(yīng)用服務(wù)層：定義軟件要完成的任務(wù)，并且指揮表達領(lǐng)域概念的對象來解決問題。這一層所負責(zé)的工作對業(yè)務(wù)來說意義重大，也是與其他系統(tǒng)的應(yīng)用層進行交互的必要渠道。應(yīng)用層要盡量簡單，不包含業(yè)務(wù)規(guī)則或者知識，而只為下一層中的領(lǐng)域?qū)ο髤f(xié)調(diào)任務(wù)，分配工作，使他們互相協(xié)作。它沒有反應(yīng)業(yè)務(wù)情況的狀態(tài)，但是卻可以具有另外一種狀態(tài)，為用戶或者程序顯示某個任務(wù)的進度。

領(lǐng)域服務(wù)層：負責(zé)表達業(yè)務(wù)概念，業(yè)務(wù)狀態(tài)信息以及業(yè)務(wù)規(guī)則。盡管保存業(yè)務(wù)狀態(tài)的技術(shù)細節(jié)是由基礎(chǔ)設(shè)施層實現(xiàn)的，但是反應(yīng)業(yè)務(wù)情況的狀態(tài)是由本層控制并且使用的。領(lǐng)域?qū)邮菢I(yè)務(wù)軟件的核心。

基礎(chǔ)設(shè)施層：為上面各層提供通用的技術(shù)能力，為應(yīng)用層傳遞消息，為領(lǐng)域?qū)犹峁┏志没瘷C制，為用戶界面層繪制屏幕組件（PS：這個在互聯(lián)網(wǎng)應(yīng)用中幾乎用不到）等等。互聯(lián)網(wǎng)Web應(yīng)用系統(tǒng)中基礎(chǔ)設(shè)施包含了數(shù)據(jù)持久化服務(wù)，中間件服務(wù)（數(shù)據(jù)庫，Redis，Memcached，zookeeper，ELK等等）以及第三方服務(wù)等。

各層除了實現(xiàn)自己的功能外，還需要遵守以下原則：

每一層設(shè)計保持內(nèi)聚，并且只依賴于它的下方的層。

下層向上層發(fā)起的通信只能通過中間件等間接方式進行。[2]

上層和下層只能有松散耦合（各自為獨立個體，通過簡單引用關(guān)聯(lián)）。在某些微服務(wù)框架比如Dubbo中，可以把api包提供給上層引用即可。這也符合依賴倒置原則。

這里重點說明應(yīng)用服務(wù)層和領(lǐng)域服務(wù)層之間的關(guān)系。舉一個我經(jīng)常跟部門其他開發(fā)舉的一個例子：有一家上市企業(yè)A公司，靠賣水果發(fā)家，其首席架構(gòu)師科學(xué)合理的按照DDD搭建了一套基于微服務(wù)體系的賣水果應(yīng)用，其架構(gòu)圖如下：

今年水果行情一般，而房地產(chǎn)十分火熱，A公司高層發(fā)現(xiàn)房地產(chǎn)帶動的五金行業(yè)也十分火熱，于是下達任務(wù)給技術(shù)部，要求其立即著手搭建五金銷售系統(tǒng)，貨源已經(jīng)談好。得益于首席架構(gòu)師之前優(yōu)秀的架構(gòu)設(shè)計，他發(fā)現(xiàn)只需要做一個賣五金的網(wǎng)站以及另外對微服務(wù)進行微量的調(diào)整即可滿足老板的需求——因為賣五金和賣水果并無本質(zhì)區(qū)別，他們涉及的環(huán)節(jié)幾乎一致。加入五金售賣的系統(tǒng)架構(gòu)圖如下：

可見應(yīng)用服務(wù)層代表是某一個業(yè)務(wù)應(yīng)用，它代表的更多的是從需求出發(fā)的應(yīng)用定義，而領(lǐng)域服務(wù)層則是業(yè)務(wù)領(lǐng)域按照自身的邊界進行設(shè)計的一個高內(nèi)聚的服務(wù)體。應(yīng)用層通過協(xié)調(diào)和組合各個領(lǐng)域服務(wù)即可形成一個新的應(yīng)用服務(wù)。《領(lǐng)域驅(qū)動設(shè)計》中明確指出，在設(shè)計領(lǐng)域服務(wù)時無需考慮表示層和持久層服務(wù)的東西。我在現(xiàn)實開發(fā)中總是遇到大量工程師按照產(chǎn)品的設(shè)計稿一溜煙的從上至下設(shè)計應(yīng)用層服務(wù)和領(lǐng)域?qū)臃?wù)，完全沒有考慮業(yè)務(wù)領(lǐng)域的概念，導(dǎo)致后面微服務(wù)數(shù)量膨脹，功能重復(fù)度高。這種開發(fā)習(xí)慣代表的是《領(lǐng)域驅(qū)動設(shè)計》作者極力吐槽的一種模式——SMART UI “反模式”[5]。

4.領(lǐng)域劃分和微服務(wù)化

根據(jù)DDD理論，領(lǐng)域建模主要發(fā)生在領(lǐng)域服務(wù)層，各領(lǐng)域模塊都應(yīng)該是高內(nèi)聚低耦合的，具有清晰的業(yè)務(wù)邊界。本文不打算討論具體的DDD建模（服務(wù)，工廠，倉庫，實體，值對象，聚合等），這需要對DDD有較深入的研究，就目前所從事過的公司來看，似乎沒有一家真正嚴(yán)格按照DDD進行項目代碼設(shè)計的，就像摘要中說的，這對整個軟件工程鏈路上的人員都有較高的要求。

有機會可以單獨寫一篇關(guān)于自己對DDD建模的思考和建議，本文更多的是討論高視角下的領(lǐng)域服務(wù)拆分，從而搭建一個低耦合高內(nèi)聚的微服務(wù)體系。如果一定要將微服務(wù)和DDD聯(lián)系起來的話，領(lǐng)域?qū)拥奈⒎?wù)就對應(yīng)了DDD中的領(lǐng)域模塊Module，每個Module由多個Service模式對象以及對應(yīng)的模型對象（實體, 值對象以及它們的聚合）組成。

“從《領(lǐng)域驅(qū)動設(shè)計：軟件核心復(fù)雜性應(yīng)對之道?！分形覍W(xué)到的主要有兩塊：領(lǐng)域設(shè)計思想和領(lǐng)域建模模式。本文更多的是對前者的運用，后者的對立模式是貧血模型，大家日常用到的也都是貧血模型，我也覺得貧血模型有存在的必要性，所以本文我們主要從其中借鑒一下領(lǐng)域設(shè)計思想。本文所描述的設(shè)計理念，并不影響具體的模型設(shè)計方法，我們?nèi)匀豢梢栽诿總€微服務(wù)中使用DDD領(lǐng)域建模。”

如何切分領(lǐng)域模塊并沒有一個明確的規(guī)則，不同的場景下可能相同的業(yè)務(wù)塊邊界也不盡相同。這里提幾點領(lǐng)域劃分的個人心得：

領(lǐng)域設(shè)計一定要有清晰的功能邊界。一個領(lǐng)域服務(wù)對應(yīng)了一個功能集合，這些功能一定是有一些共性的。比如，訂單服務(wù)，那么創(chuàng)建訂單、修改訂單、查詢訂單列表，一般是訂單域的功能集合。

領(lǐng)域拆分并不是一步到位的，應(yīng)當(dāng)根據(jù)實際情況逐步展開。從單體應(yīng)用到微服務(wù)體系的拆分過程能很好的說明這個問題，一上來拆的很細的改造方案一定會死的很慘。所以如果一開始不知道應(yīng)該劃分多細，完全可以先粗粒度劃分，然后隨著需要，初步拆分。比如一個電子商務(wù)網(wǎng)站開發(fā)一開始索性可以拆分為商品服務(wù)和交易服務(wù)，一個負責(zé)展示商品，一個負責(zé)購買支付。隨后隨著交易服務(wù)越來越復(fù)雜，就可以逐步的拆分成訂單服務(wù)和支付服務(wù)。

領(lǐng)域拆分并不是一成不變的，應(yīng)當(dāng)具體情況具體分析。2015年在大眾點評的時候，其訂單服務(wù)就拆分為了order-service和order-query-service，一來為了讀寫分離，二來order-query-service作為單獨應(yīng)用可以按需水平擴容。

領(lǐng)域可以是多個子領(lǐng)域的一個虛擬集合，換句話說多個微服務(wù)也可以形成一個大域，不必糾結(jié)于領(lǐng)域和微服務(wù)之間的數(shù)量對應(yīng)關(guān)系。我們在做架構(gòu)設(shè)計PPT的時候可能就把訂單域作為一個領(lǐng)域，代表了這個域就是關(guān)于訂單的，具體該有幾個微服務(wù)，這需要更細的詳細設(shè)計來提供。

領(lǐng)域?qū)臃?wù)設(shè)計應(yīng)當(dāng)是調(diào)用者無關(guān)的。這一點有點像第一點，但是它強調(diào)的是領(lǐng)域?qū)臃?wù)的設(shè)計不應(yīng)該受調(diào)用者的影響，這個觀點在《領(lǐng)域驅(qū)動設(shè)計：軟件核心復(fù)雜性應(yīng)對之道》這本書里也可以找得到[4]。領(lǐng)域?qū)臃?wù)開發(fā)和設(shè)計的理念是關(guān)注自己的域，一旦邊界劃分清楚了，開發(fā)所需要考慮的永遠都只是輸入和輸出，提供的服務(wù)一定是盡可能通用的，面向功能來開發(fā)的，而不是面向調(diào)用方來開發(fā)的。比如某個調(diào)用方提出了一個需求：調(diào)用方B希望A服務(wù)提供一個買汽車的接口，那么A服務(wù)設(shè)計的接口就應(yīng)該是buyCar()，而不是buyCarForB()。

5.Q&A

5.1 能不能在所有層使用數(shù)據(jù)持久層模型，簡單快捷？

大家一定聽說過不同層的數(shù)據(jù)模型的叫法不同的概念，比如數(shù)據(jù)持久層的模型對象叫DBO（database object）或者DPO（data persistence object),領(lǐng)域?qū)拥哪Ｐ蛯ο蠼蠨MO（Domain Model Object）或者就叫Model，數(shù)據(jù)傳輸層的模型對象叫DTO（Data Transfer Object)。那為啥要這么多模型呢，直接使用Mybatis等ORM框架生成DBO，然后一路吐給前端不是更爽（還真有同事嘗試立項寫Mybatis插件來實現(xiàn)這種所謂的代碼自動化）。

我個人建議如果您真的是要搭建一個復(fù)雜的大系統(tǒng)，大平臺，一定不要偷這種懶，最好的就是做到”一層一模型”（網(wǎng)關(guān)層使用應(yīng)用層模型即可）。各層之間采用手動的數(shù)據(jù)賦值（getter，setter）來完成，或者使用一些轉(zhuǎn)換框架來簡化轉(zhuǎn)換代碼，個人在用getter/setter時感覺并不會耽誤什么，在一個個set的時候，恰好可以對模型的字段細節(jié)進一步確認(rèn)，并且拒絕使用BeanUtils.copyProperties()這種工具類，因為這樣的工具類會讓”一層一模型”形同虛設(shè)，開發(fā)會熱衷于把DPO拷貝到領(lǐng)域中換個名字以保證可以用拷貝工具。下面我們來細談下不能在每一層都是用數(shù)據(jù)持久層模型的具體原因：

應(yīng)用層對接網(wǎng)關(guān)層，是向面向C端或者調(diào)用者的一個數(shù)據(jù)出口，但是調(diào)用者只需要這個出口輸出用戶感興趣的數(shù)據(jù)，并且有些敏感數(shù)據(jù)不能吐出去。如果應(yīng)用層（面向調(diào)用者）使用的仍然是數(shù)據(jù)庫模型，而開發(fā)人員沒有在應(yīng)用層把無關(guān)值置空的話（相信我，需求一多，工作一忙，鬼才會在意這些細節(jié)），那么數(shù)據(jù)庫里的整條記錄就作為接口輸出吐出去了。比如訂單記錄，用戶訂單列表可能只需要訂單ID，商品名稱，訂單金額。而像商家結(jié)算價這種就不能吐出去，萬一被有心人察覺到了，用戶一定會投訴——你跟商家結(jié)算價200，賣給我400？

前端或者接口調(diào)用方會很痛苦，一個接口契約多一兩個無關(guān)字段是沒關(guān)系的，但是一個契約里給的30個字段，我只用到5個，前端會罵娘的，我親眼見過這種事，設(shè)計原則里有個原則叫”迪米特法則”，也叫最小知識原則，接口設(shè)計也可以參考這個原則，盡量讓你的調(diào)用方知道盡可能少的信息點就能完成相關(guān)的任務(wù)。

“一層一模型”本質(zhì)是解耦模型依賴。我在上家公司做架構(gòu)師時為了兼顧開發(fā)的感受，決定讓他們可以在領(lǐng)域?qū)雍突A(chǔ)設(shè)施層都是用數(shù)據(jù)持久層模型，而只需要在應(yīng)用層做數(shù)據(jù)控制（解決第一個問題），然而我的妥協(xié)也慢慢露出弊端，開發(fā)有時候覺得某個數(shù)據(jù)庫字段命名不合適修改之后，整個引用了該模型的微服務(wù)都需要修改，如果一層一模型的話，只需要關(guān)聯(lián)數(shù)據(jù)庫訪問的服務(wù)修改下DPO和DM的映射就行了，其他上層微服務(wù)都是依賴DM的。雖然我們不鼓勵隨意改動數(shù)據(jù)庫字段，但設(shè)計框架上最好能支持這種情況。

剛開始推廣”一層一模型”的時候，會有耍小聰明的開發(fā)去把下一層的模型POJO直接拷貝過來改個名字，然后用BeanUtils.copyProperties()完成賦值，這樣跟直接使用數(shù)據(jù)持久層模型就沒有區(qū)別了，所以要杜絕這種情況的發(fā)生。

5.2 為啥需要應(yīng)用層，領(lǐng)域?qū)游⒎?wù)直接通過網(wǎng)關(guān)暴露不就行了嗎？

對于習(xí)慣了單體應(yīng)用開發(fā)者來說，一個微服務(wù)很可能就直觀對應(yīng)成了一個個垂直的應(yīng)用服務(wù)，每個服務(wù)間的關(guān)系是這樣的： 

6.結(jié)語

總結(jié)：

做Java生鮮電商平臺的互聯(lián)網(wǎng)應(yīng)用，無論是生鮮小程序還是APP，微服務(wù)系統(tǒng)是非常重要的，本文只是起一個拋磚引玉的作用，希望用生鮮小程序的微服務(wù)拆分的實戰(zhàn)經(jīng)驗告訴大家一些實際的項目經(jīng)驗，希望對大家有用。

文章來源：架構(gòu)之家；

編輯：云朵匠 | 數(shù)商云(微信ID：shushangyun_com)

【數(shù)商云www.zhimaihui.cn】致力于提供企業(yè)級的電商平臺服務(wù)，長期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的電商系統(tǒng)開發(fā)解決方案，同時我們還提供B2B交易系統(tǒng)、B2B2C多用戶商城系統(tǒng)、B2C電子商務(wù)系統(tǒng)、跨境進口電商平臺、供應(yīng)商系統(tǒng)、SRM供應(yīng)商管理系統(tǒng)、SCM系統(tǒng)、渠道管理系統(tǒng)等一系列系統(tǒng)定制開發(fā)服務(wù)，通過大數(shù)據(jù)、云計算等新技術(shù)協(xié)助企業(yè)打造供應(yīng)端—渠道端—營銷端—數(shù)據(jù)端等全鏈數(shù)字化運營體系，提升企業(yè)運營效益與智慧數(shù)字化商業(yè)轉(zhuǎn)型。