虽然单体应用程序也可以实现相当好地建模，但它们常常会演变成一团乱麻。究其原因是单体应用程序内的多个领域模型错综复杂地交织在一起。根据Vaughn Vernon的经验，这种情况在几周或几个月内就会出现。在今年早些时候举行的Scala Days大会上，他在演讲中表达了这样的观点。
Vernon是《实现领域驱动设计》和《通过Actor模型实现响应式消息处理模式》这两本书的作者。他指出，当应该保持独立的领域模型混在了一起，互相无法区分时，就很难或者不可能和业务及领域专家一起从逻辑上推断模型，让应用或系统比单体应用程序还糟糕。
单体应用程序的一个替代方案是微服务，但我们如何定义一个微服务？它有多大？有时候，人们提出使用代码行定义微服务的大小，Vernon见过以数十行为标准的，也见过一上千行为标准的，但他不主张采用这样一种既宽泛又不准确的定义。
此外，有些企业号称有数以百计的微服务，但又不知道或者不关心准确数值。他们认为，不值得花费时间和精力去弄清它们的实际使用情况，因为，只是让它们运行起来的话，成本会很低。Vernon对此作出了回应。他不同意这样的观点。他指出，别的不说，基础设施对于许多微服务如何运行，如何在故障情况下保持弹性，有重大的影响。
Vernon建议采用一种规定性的方法确定一个系统里微服务的大小和数量：使用领域驱动设计（DDD）的方法，尤其是有界上下文。他指出，在微服务社区里，有时候会将有界上下文定义成只有一个实体，但他发现那不大可能。相反，Vernon支持借助通用语言在大小确定的有界上下文中建模微服务，并提到了Sam Newman的著作《构建微服务》。
在开始使用微服务的时候，Vernon建议从每个有界上下文一个微服务开始。他认为，即使我们能够在一个有界上下文中找出多个本身可以视为微服务的组件，但它们的内聚性和协同关系意味着它们应该一起放在一个服务里。他还建议，一个服务和一个有界上下文应该是一个可部署的单元。尽管如此，根据经验，他们可能会采用更细的粒度，为一个有界上下文创建更多的微服务和可部署单元，可能是因为扩展性方面的原因。
除了实体之外，通用语言还包括命令和事件消息。通过发布最终供其他微服务使用的事件，消息可以用在事件驱动的架构中。在演讲总结阶段，Vernon展示了一个构建微服务的例子。该例子使用了Actor模型，并使用Akka和Scala实现。
====================================分割线================================
本文转自d1net（转载）