我一直在寻找SOA和Microservices架构风格之间的差异，并找到了一个很好的链接https://www.infoq.com/articles/boot-microservices
它说：
作为“面向服务的体系结构”（SOA）的继承者，微服务可以归入同一类“分布式系统”中，并继承了许多相同的SOA概念和实践。但是，它们的区别在于对单个服务的责任范围。在SOA中，服务可能负责处理各种功能和数据域，而微服务的一般准则是它负责管理单个数据域以及该域周围的相应功能。
请帮助我了解：
单个数据域的含义（建议用于微服务）。是说必须构建一个单独的微服务来管理单个域/实体（以及与此单个域/实体相关联/复合的域/实体）。因为如果是这种情况，那么即使要实现基本功能（企业）应用程序，也会有许多（〜20到〜50）个微服务
编辑：我已经看过微服务架构和SOA之间的链接差异，但是它解释说，它在前两个原则上是相同的，在第三点上是不同的（在SOA中，服务共享模式和协定，而不是类），但是是SOAP合同，但是黑白SOA（使用REST）与微服务（主要是使用REST）有什么区别？
小智 6
补充一下 Sean 所说的，当 SOA 开始在许多公司中使用时，人们开始将微服务称为 API。领域驱动设计的兴起也导致了该术语的使用量增加。在现在的行业里，两者完全没有区别，人们称其为合适。
当你说当你遵循原则时你最终会得到许多微服务时，你是对的。在我看来，无论是 SOA 还是微服务，对独立服务的抽象应该仅取决于用例、服务将如何部署以及有多少团队将并行处理这些服务。如果服务跨主机部署，网络带宽的成本也会增加（尽管容器和 DC/OS 框架现在正在解决这个问题）。如果它是快速变化的服务，有很多移动部件，那么将大型服务分解为微服务是有意义的。否则，我会避免过早优化，并将功能打包到单个（或几个大的）服务中。
我认为这是一个解释问题：
我认为，在 SOA 中，aservice不是一个物理过程（Windows 服务/应用程序域），而是一个逻辑边界……并且相同的规则适用于 SOA 和微服务中最小的自治组件。他们拥有（技术权威和数据所有者，这意味着他们是唯一可以更改该数据状态的组件）一个或多个域属性/字段的集合。
现在在运行时，我认为如果您不需要分发进程，那么您可以将它们全部部署在同一个进程中（稍后当您需要扩展时，分发组件以获得更好的性能）...
合理？