我的项目有一个后端服务（Web API）和一个前端 SPA 应用程序。后端服务具有位于不同 .net 程序集中的表示层、应用程序服务、域和基础设施层。领域层有业务领域对象、基础设施——与外部数据和其他东西的通信、应用程序服务——表示层使用的一组服务、表示——Web API 控制器。我认为这是非常常见的分层架构。
我们的新架构师宣布我们将把后端迁移到微服务架构，分解我们的层，将域、应用程序服务和基础设施层划分为几个服务，并将表示层转换为前端层的后端（如此处所述）。在功能方面，我们将有移动应用程序。Sql Server 数据库现在将保持原样。
我没有微服务架构的经验，所以我的问题是：多层架构已经过时了吗？这样的架构设计能给我的应用带来什么好处和问题？
微服务和分层架构有点不同。微服务架构是关于你的应用程序是如何构建的，它有哪些组件（服务）以及这些服务如何相互通信，它们是如何开发、部署的等等。
多层架构是将应用程序逻辑划分为层，其中每一层都有自己的逻辑功能（表示、域等）。很多时候，多层架构与单体架构和服务设计有关。
根据您的描述，您不会分解您的层，您的架构师希望将逻辑拆分为不同的服务。这两种架构风格可以一起使用。例如，您可以有 3 个服务，每个服务都可以有表示层、域层和服务层。如果您当前在一项服务中的层足够重，那么将它们分开以使开发和测试更容易是有意义的。前端风格的后端也有它的好处，特别是如果你想添加一个移动应用程序。
对这个
多层架构已经过时了吗？
不，它们都被使用，但作为规则，微服务层应该比单片应用程序薄得多。
这样的架构设计能给我的应用带来什么好处和问题？
我建议您查看微服务和单体架构风格之间的比较以及这篇文章。要划分与否，您应该考虑项目的规模和复杂性，以及团队的规模。划分必须为整个应用程序带来好处，使开发更容易。Monolithic 应用程序有其自身的优势，并且在项目规模达到一定规模时，它可能是一个不错的决定。当然，与庞大的单体应用程序以及一百个非常小的（纳米）服务一起工作是一场噩梦。
感谢分享！
总之，单体和微服务结构都有其优点和缺点，选择正确的选项取决于您的截止日期、开发团队以及您的应用程序在部署后将面临的负载。
如果以下任何选项与您有关，请确保整体结构对您的应用程序来说足够好：
小应用程序。您的应用程序非常简单，部署后不会遇到严重的负载，或者它已经投入生产，但还没有遇到任何性能问题。
快速启动。你有一个新的想法或一个初创公司，应该尽快推出，因为目前它没有任何竞争对手，你的项目将有机会成功。想法实施的最后期限紧迫。预算有限。
概念证明。您想通过为目标受众构建基本产品来检查您的想法是否可行和有用。
没有微服务经验。您的团队不够大，无法将人员分开来设计单独的微服务，或者您的团队没有构建它们的经验。当然，最好开始学习和实践微服务，但应该成为应用程序骨架的功能并不是最好的机会。
如果您知道在什么情况下选择后者，单体架构与微服务架构是一个更容易回答的问题。
复杂的应用程序。您的应用程序足够复杂，无法集成新工具，或者遇到无法通过垂直扩展解决的负载问题，或者在这种情况下无利可图。
计划发展和扩展应用程序。您的项目经历了稳定的负载增长，并且您计划集成新工具，但是当可能出现扩展问题时，应用程序有可能达到临界点。
有微服务经验。您的团队中有一些开发人员在设计微服务并将其部署到生产环境方面经验丰富，并且您确信团队中有一部分人将在他们从事微服务工作时支持和开发主应用程序。
乌托邦。你有足够的钱、忠诚的经理和延长的期限。
现在，单体与微服务的选择应该更容易做出。