什么樣的服務才是好的服務?

? ? ??高內聚、松耦合的服務才是好的服務。簡而言之，就是把相關性強的放在一起，相關性不強的分開，物以類聚，人以群分，服務的劃分也是這樣。這就需要確定什么要放在一起，什么是要分開的，這個尋找的過程就是確定服務邊界的過程。

?

限界上下文

? ? ? ?限界上下文確定了這個邊界內它所承擔的職責。

? ? ? Evans在《領域驅動設計》中作喻：細胞之所以會存在，是因為細胞膜定義了什么在細胞內，什么在細胞外，并且確定了什么物質可以通過細胞。這是限界上下文的絕好比喻。

? ? ? 任何一個給定的領域都包含多個限界上下文。限界上下文中包含了一些內容（或者叫模型），它們的相關性較高，一部分需要與外部通信，一部分不需要與外部通信，每個限界上下文都有明確的接口，該接口決定了它會暴露哪些模型給其他的上下文。外部想與限界上下文通信，需要使用模型和它的顯式限界（接口）進行通信。這樣做可以得到高內聚，從而很好地形成組合限界。

? ? ? 限界與限界之間，也會存在共享模型，如下所示，倉庫和財務都需要庫存信息，但不能把倉庫所有的庫存信息都給財務，因為有些信息對于財務是并沒有用的，同時也不能讓財務伸到倉庫內部去取數據，這樣有可能會破壞限界上下文的完整性，因此，我們提供了一個共享模型——庫存項。

? ? ? ? ? ? ? ? ??

? ??? 這些模塊限界就可以成為絕佳的微服務候選，一般來說，微服務應清晰地和限界上下文保持一致。

?

如何確定限界上下文

??? ??1.推薦使用領域來表分解限界上下文

? ? ? 如果把系統分解成為限界上下文來表示領域的話，那么對于某個功能所做的修改，就更傾向于在一個單獨的微服務限界之內。另外，服務之間應該共享相同的術語，也應該反映到服務的接口上。

? ? ??2.應從限界上下文提供的功能來考慮，而不是數據

只考慮數據和模型，不考慮上下文的功能，很容易導致“貧血”，所以要先問“這個上下文是做什么用的“，再考慮它”需要什么樣的數據“。

? ? ??3.不要過早劃分上下文

? ? ? 對于一個新系統而言，可以先使用一段時間的單塊系統，因為如果服務之間的限界搞錯了，后面修復的代價就會很大，所以最好能夠等到系統穩定下來之后，再確定把哪些東西作為一個服務劃分出去。

? ? ??4.不要排斥嵌套上下文

? ? ???一開始，你會識別一些粗粒度的限界上下文，而這些限界上下文可能又包含一些嵌套的限界上下文。如下所示：使用這些嵌套的上下文不直接對外可見，對于外界來說，它們用的還是倉庫的功能，但發出的請求其實被透明地映射到了兩個或更多有服務上。

? ? ? ? ? ? ? ?

? ? ??當然，根據每個團隊的情況不同，我們也可以將倉庫的內的上下文再隔離出來，如下所示：

? ? ? ? ? ? ??

? ??? 5.謹慎根據技術邊界來確定上下文

? ? ? 一般而言，我們建議按照業務的垂直劃分來建立上下文，而不是按照技術的分層來確定上下文，比如，你如果將DAO、BLL、UI層分成3個不同的服務，那么當你需要變更業務的時候，你需要頻繁地同時修改兩個服務，這樣顯然是不合理的。但也不是說這樣劃分總是不合理，如果一個組織想達到某個性能目標，這樣劃分反而更合理。

? ? ??

參考

? ? ? 《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）

相關文章：?

• 微服務的概念——《微服務設計》讀書筆記

• 微服務架構師的職責——《微服務設計讀書筆記》
  

原文地址：http://www.cnblogs.com/gudi/p/6613989.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的建模:确定服务的边界——《微服务设计》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。