著名DDD社区意见领袖Nick Tune撰文认为微服务就是领域服务，建议使用领域服务替代微服务，banq赞成这种做法，在我的DDD书籍中已经将这两个概念混为一谈，当然他们还是有细微差别，比如微服务可能有关技术或应用方面功能例如增删改查CRUD可以在微服务中实现，但是不是好的领域服务功能，因为CRUD是一种数据库操作概念，是业务逻辑相当简单甚至为零的领域服务功能，当然它也对应API的POST/PUT等资源操作，从CRUD角度能够学习理解微服务 领域服务和领域API. 下面是ntcoding原文翻译，原文点击标题。
微服务时代到来对于软件架构来说是一个好时机。我记得当年如果你有想设计多个数据库的想法时，会立即被当时人们处以死刑。但是，对微服务的过度关注已经削弱了微服务的真正好处，即提高服务质量和开发速度。
在过去的几年中，我看到人们将微服务称为领域服务。我已经从这种小型重组中看到了好处，我现在建议不要使用单词微服务microservice，而是使用领域服务Domain Service。
对微服务的批评很多，而且还有很多恐怖的故事。但是，我不希望对微服务进行口口相传，以大肆宣传一个新的流行语。对于微服务运动取得的成就，我将不胜感激，这些想法应继续得到应用。
任何可以使用的东西都可能被滥用。所有的好主意和概念都可能以错误的方式应用。我们的工作是在行之有效的基础上，改进行之有效的方法。我已经看到将微服务框架化为领域服务保留了松散耦合的优势，并消除了对微服务的痴迷。
微服务也有很多负担，通常会抵消有关其优点的讨论。这主要是由于应用不当，人们指责微服务，而不是有关概念本身的任何事情。
什么是领域服务或领域API？
领域服务建立在微服务的基本定义之上：它是一个松散耦合的，可独立部署的软件体系结构元素，由一个团队拥有。
重要的是，领域服务的重点在于它代表了一个专业领域，企业在该领域中开发能力以向客户交付产品和价值主张。
领域是企业逻辑体系结构的一部分。组织构建的产品可以为客户群提供价值主张。产品由逻辑上存在于业务领域中的功能提供支持。
业务领域通常是多个团队在其中开展业务开发的领域。一个业务域可以细分为多个子域。领域服务的建议边界是子域，因为对于单个团队来说，边界不应太大。
业务域通常是由多个子域组成的大部分业务区域。
举一个具体的例子，这是Uber的定义以及他们业务中的一些真实例子：
Uber领域代表与功能的逻辑分组相关联的一个或多个微服务的集合。设计域时常见的问题是“域应该有多大？”
我们在此不提供任何指导。有些域可以包含数十个服务，有些域只能包含一个服务。重要的任务是仔细考虑每个集合的逻辑作用。例如，我们的地图搜索服务构成一个域，票价服务是一个域，匹配平台（匹配的骑手和驾驶员）是一个域。这些也不总是遵循公司的组织结构。
Uber Maps地图组织本身又分为三个域，在三个不同的网关后面有80个微服务。
Uber不使用术语“子域”，他们更喜欢使用微服务。实际上，它们在域中的每个服务都代表该域的一部分，我称之为子域，但是您可以决定将其命名为不同的东西。
新构架，新问题
毫无疑问，微服务已证明命名很重要。我认为我们所有人都参与了许多关于“微服务应该有多大？”的辩论，人们拿起材料告诉我们微服务应该是100行或更少的代码行。即使在2021年，作为顾问和培训师，这仍然是我一生中经常遇到的问题。
因此，更改名称（将微服务更名为领域服务）将产生重大影响。有可能会失去当前的某些优势并可能引入新的问题。我看到的新问题是，现在人们在问“什么是领域？”，“我们如何找到领域边界？”，“我们如何命名领域API？”。但是，这是一件好事。这些是我们希望人们提出的问题，因为它们与理解业务以及使体系结构的设计与业务保持一致有关。
其他缺点肯定会出现。每个想法都可能被滥用和错误应用，尤其是好主意。我绝不暗示这是架构的终结，但我已经看到了足够的证据表明这是向前迈出的一大步。
改变叙事方式可以提高利益相关者的参与度，在使用术语“领域服务”或“领域API”时，我发现产品所有者/经理，业务分析人员以及组织中的其他同事更加感兴趣，他们更加注重业务，技术含量较低。
我的感觉是，微服务被非工程师和非架构师视为纯粹的技术概念。我通常不会看到那些使用微服务一词或参与有关微服务的对话的人。
在谈论领域服务/ API时，我看到那些人更舒适地使用这些术语，并进行了相对详细的对话，涉及定义领域服务的边界，业务规则如何在域服务中而不是在BFF中存在，以及对帮助命名的真实渴望。包括领域服务，API端点及其代表的概念。
不捆绑任何方法论或框架
品牌重塑尝试通常用于宣传新的头或使新的思想领袖建立自己的形象。这不是尝试这样做。实际上，将微服务重新定义为领域服务并不依赖于任何想法或框架。这更多是为了改善协作和设计文化。
去年，Uber在Uber上发布了面向领域的微服务，向我们展示了微服务的发展，使其更加注重领域。但是您不需要遵循他们的方法。域驱动设计已经存在了将近20年，但是您无需阅读，学习或应用任何有关域驱动设计的知识，就可以对软件体系结构采用更加面向领域的方法。
无需重写系统
好的微服务架构（MSA）已经是好的面向领域的架构（DOA）。无需重新设计和重写您的系统即可与最新的体系结构流行语兼容。
如果您确实查看了微服务架构，并且觉得它不是非常面向领域的，那么这就是考虑重新设计的一个很好的理由，因为您正在改进架构的设计，而不是尝试与流行语兼容。
从现在开始…
不是我开始调用微服务域服务或域API的趋势。在过去的几年中，我已经看到它在一些大客户中有机地发生了。但是，我觉得以业务为中心的框架会导致更好的对话和更好的设计架构，从现在开始，我将使用术语域服务和域API。希望取得积极成果的趋势将继续下去
DDD+微服务大型案例：Uber如何从复杂的RPC微服务转向面向业务领域的微服务架构DOMA？ -优步工程博客