问分层架构是否仍需在所有其他架构模式(如SOA和Microservices )中实现？

EN

都是关于语义学的。

强制层将有助于保持代码在职责上的清洁。(单一责任原则)。当你将关注点分开时，你的心理堆栈将在每一层中被最小化。你可以在交换层中获得灵活性。

使用层是组织代码质量的垂直方式。组织人员也是如此。如果你有更多的人，你必须花更多的时间来组织他们。

对于微型服务而言，有一件事：

它们不嵌入层，它们以水平方式(功能方式)组织代码质量。这里再次:更多的代码，更多的分离。但要小心：

如果Microservices忽略了您整个领域的“更大”上下文，它们可能会放弃一致性。因此，如果我设计微服务，它们是考虑到全局一致性的业务域模型部分的出站视图。

因此，在大多数情况下，我不会将业务层划分成更小的部分，因为您可能会失去检查全局约束的可能性，否则您将不得不在您的微服务协议中考虑这些一致性约束，使它们变得更加复杂。

对我来说，UI、Usecases、业务逻辑和DAO层在语义上是必不可少的和统一的。我不认为我们需要讨论UI。Usecases将对用户当前的工作流程进行建模。业务逻辑将检查本地和全局约束，以确保系统范围的一致性，此外，它还负责编排DAO。DAO层将从数据持有者的类型中提取。

毕竟，只有一件事是重要的:你为之工作的企业的最大利润。因此，你的开支分开关注，应该平衡与收入的实现与申请最大的利润。

大多数领域驱动的设计领导者更喜欢将微服务与有限制的上下文(EricEvans-DDD和微服务:终于，一些界限！和Vernon说使用领域驱动设计(DDD)方法，特别是有界上下文.)相结合。如果你遵循DDD领导者的建议，你就不会得到很小的服务。这意味着仔细构建服务内部的代码也是有益的。

然而，正如沃恩·弗农在他的IDDD书中所说的那样

这些天来，许多声称他们正在使用层体系结构的团队实际上正在使用六边形。

六角(也称为端口和适配器)具有良好的依赖反转原理和良好的支持不同平台依赖注入的概念，易于实现。

在问题中的ThumpImageService示例中，它看起来非常简单。问题是，这个服务是否总是如此简单，例如，是否涉及到管理其他资源，您是否会在每个主题/配置文件中有不同的thump图像。另一个问题是，您的大多数服务是否如此简单。重点是微服务或DDD更适合用于“解决软件中心的复杂性”。我非常喜欢"DDD记分卡“( IDDD书中)的想法。在深入之前，我们应该对项目进行评分，并评估项目是否值得这样的开销。

当您将ui、api、数据或逻辑层与Docker混合时，您在这里谈论苹果和桔子。Docker是一个实现关注点；架构模式是概念性的。

容器模型允许您将应用程序的各个层(如果是这样构建的话)部署到单个容器中。理论上，您可以在同步或异步连接在一起的Docker容器集群中运行ui、api、数据或逻辑层。另一方面，如果应用程序占用的空间很小，则可以将它们都混合到一个容器中。

您需要做的是首先分析您正在做的事情，然后将其分解为逻辑组件。这在很大程度上取决于您的项目有多大，它对可伸缩性和可靠性的要求，以及它存在多长时间的现实情况。

模式只是指南，必须根据您自己的需要进行评估。为小用户基础的小项目？当成本不符合业务案例的要求时，您可能会浪费大量时间尝试创建一个概念优雅的体系结构。大型项目，多个开发团队，产品寿命长.那么模式是必不可少的，否则你就会迷失方向。

架构层不仅对于分离开发和测试关注点，而且对于实现更可伸缩的系统都是有意义的。例如，由于API层通常必须具有极强的弹性和响应性，您可能需要一个更大的面向用户的容器集群，这些容器可以始终响应请求。另一方面，您可能有各种容易使用的业务逻辑组件，因此可以在单个容器中运行。

换句话说:知道你在做什么，弄清楚它是如何部署的，然后看看架构层对于创建一个长期运行和稳定的系统是有意义的。