雖然單體應用程序也可以實現相當好地建模，但它們常常會演變成一團亂麻。究其原因是單體應用程序內的多個領域模型錯綜復雜地交織在一起。根據Vaughn Vernon的經驗，這種情況在幾周或幾個月內就會出現。在今年早些時候舉行的Scala Days大會上，他在演講中表達了這樣的觀點。

Vernon是《實現領域驅動設計》和《通過Actor模型實現響應式消息處理模式》這兩本書的作者。他指出，當應該保持獨立的領域模型混在了一起，互相無法區分時，就很難或者不可能和業務及領域專家一起從邏輯上推斷模型，讓應用或系統比單體應用程序還糟糕。

單體應用程序的一個替代方案是微服務，但我們如何定義一個微服務？它有多大？有時候，人們提出使用代碼行定義微服務的大小，Vernon見過以數十行為標準的，也見過一上千行為標準的，但他不主張采用這樣一種既寬泛又不準確的定義。

此外，有些企業號稱有數以百計的微服務，但又不知道或者不關心準確數值。他們認為，不值得花費時間和精力去弄清它們的實際使用情況，因為，只是讓它們運行起來的話，成本會很低。Vernon對此作出了回應。他不同意這樣的觀點。他指出，別的不說，基礎設施對于許多微服務如何運行，如何在故障情況下保持彈性，有重大的影響。

Vernon建議采用一種規定性的方法確定一個系統里微服務的大小和數量：使用領域驅動設計（DDD）的方法，尤其是有界上下文。他指出，在微服務社區里，有時候會將有界上下文定義成只有一個實體，但他發現那不大可能。相反，Vernon支持借助通用語言在大小確定的有界上下文中建模微服務，并提到了Sam Newman的著作《構建微服務》。

在開始使用微服務的時候，Vernon建議從每個有界上下文一個微服務開始。他認為，即使我們能夠在一個有界上下文中找出多個本身可以視為微服務的組件，但它們的內聚性和協同關系意味著它們應該一起放在一個服務里。他還建議，一個服務和一個有界上下文應該是一個可部署的單元。盡管如此，根據經驗，他們可能會采用更細的粒度，為一個有界上下文創建更多的微服務和可部署單元，可能是因為擴展性方面的原因。

除了實體之外，通用語言還包括命令和事件消息。通過發布最終供其他微服務使用的事件，消息可以用在事件驅動的架構中。在演講總結階段，Vernon展示了一個構建微服務的例子。該例子使用了Actor模型，并使用Akka和Scala實現。

查看英文原文：Vaughn Vernon on Microservices and Domain-Driven Design