虽然单体应用程序也可以实现相当好地建模，但它们常常会演变成一团乱麻。究其原因是单体应用程序内的多个领域模型错综复杂地交织在一起。根据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
文章转载自 开源中国社区[http://www.oschina.net]
