• 用戶界面層：負責向用戶顯示和解釋用戶指令。這里指的用戶可以是另一個計算機系統(tǒng)，不一定是使用用戶界面的人（比如外部應用調(diào)用對應接口）。前后端分離時，該層可以扮演前端所需數(shù)據(jù)的組裝者。
• 網(wǎng)關層：負責提供對外的HTTP服務或者其他應用層協(xié)議（這里是指OSI七層協(xié)議中的應用層，別混淆了哈）服務。
• 應用服務層：定義軟件要完成的任務，并且指揮表達領域概念的對象來解決問題。這一層所負責的工作對業(yè)務來說意義重大，也是與其他系統(tǒng)的應用層進行交互的必要渠道。應用層要盡量簡單，不包含業(yè)務規(guī)則或者知識，而只為下一層中的領域?qū)ο髤f(xié)調(diào)任務，分配工作，使他們互相協(xié)作。它沒有反應業(yè)務情況的狀態(tài)，但是卻可以具有另外一種狀態(tài)，為用戶或者程序顯示某個任務的進度。
• 領域服務層：負責表達業(yè)務概念，業(yè)務狀態(tài)信息以及業(yè)務規(guī)則。盡管保存業(yè)務狀態(tài)的技術(shù)細節(jié)是由基礎設施層實現(xiàn)的，但是反應業(yè)務情況的狀態(tài)是由本層控制并且使用的。領域?qū)邮菢I(yè)務軟件的核心。
• 基礎設施層：為上面各層提供通用的技術(shù)能力，為應用層傳遞消息，為領域?qū)犹峁┏志没瘷C制，為用戶界面層繪制屏幕組件（PS：這個在互聯(lián)網(wǎng)應用中幾乎用不到）等等。互聯(lián)網(wǎng)Web應用系統(tǒng)中基礎設施包含了數(shù)據(jù)持久化服務，中間件服務（數(shù)據(jù)庫，Redis，Memcached，zookeeper，ELK等等）以及第三方服務等。

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

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

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

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

• 領域設計一定要有清晰的功能邊界。一個領域服務對應了一個功能集合，這些功能一定是有一些共性的。比如，訂單服務，那么創(chuàng)建訂單、修改訂單、查詢訂單列表，一般是訂單域的功能集合。
• 領域拆分并不是一步到位的，應當根據(jù)實際情況逐步展開。從單體應用到微服務體系的拆分過程能很好的說明這個問題，一上來拆的很細的改造方案一定會死的很慘。所以如果一開始不知道應該劃分多細，完全可以先粗粒度劃分，然后隨著需要，初步拆分。比如一個電商一開始索性可以拆分為商品服務和交易服務，一個負責展示商品，一個負責購買支付。隨后隨著交易服務越來越復雜，就可以逐步的拆分成訂單服務和支付服務。
• 領域拆分并不是一成不變的，應當具體情況具體分析。2015年在大眾點評的時候，其訂單服務就拆分為了order-service和order-query-service，一來為了讀寫分離，二來order-query-service作為單獨應用可以按需水平擴容。
• 領域可以是多個子領域的一個虛擬集合，換句話說多個微服務也可以形成一個大域，不必糾結(jié)于領域和微服務之間的數(shù)量對應關系。我們在做架構(gòu)設計PPT的時候可能就把訂單域作為一個領域，代表了這個域就是關于訂單的，具體該有幾個微服務，這需要更細的詳細設計來提供。
• 領域?qū)臃赵O計應當是調(diào)用者無關的。這一點有點像第一點，但是它強調(diào)的是領域?qū)臃盏脑O計不應該受調(diào)用者的影響，這個觀點在《領域驅(qū)動設計：軟件核心復雜性應對之道》這本書里也可以找得到[4]。領域?qū)臃臻_發(fā)和設計的理念是關注自己的域，一旦邊界劃分清楚了，開發(fā)所需要考慮的永遠都只是輸入和輸出，提供的服務一定是盡可能通用的，面向功能來開發(fā)的，而不是面向調(diào)用方來開發(fā)的。比如某個調(diào)用方提出了一個需求：調(diào)用方B希望A服務提供一個買汽車的接口，那么A服務設計的接口就應該是buyCar()，而不是buyCarForB()。