从分层架构到DDD。我的迁移和切割巨石的经历

今天我们将讨论后端应用程序的架构，并比较两种流行的项目结构方式：onion 和 DDD。我将告诉您第二种方法相对于第一种方法的优点以及我最近将项目转移到六边形架构的经验。本文适合那些已经使用过分层架构并希望了解更多内容的人（例如，开始使用微服务）。

让我们从分层架构开始。分层，也称为洋葱架构，是一种我们将整个应用程序分层的架构。每一层都有自己的功能和明确的目的。例如与数据库的交互：这样的层应该只包含与数据库交互的功能，而没有其他功能。不应与客户端或任何其他功能进行交互。

在分层架构中，后端通常有 3 个主要层：用于与存储交互、应用程序逻辑和代表层。

这是一个典型的三层架构，一切都非常简单。请求经过各个层，获取最终的形式（存储中的请求），响应进行回程，变成某种方便客户端的格式（JSON、XML等）。

我在我的所有项目和我参与的初创公司中已经使用这个架构很长时间了。在小型宠物项目中，这种方法确实有效并且不会引起问题，但在较大的项目中，混乱就开始了。

分层架构的主要原则之一是能够用相似的层替换任何层，从而根本不需要更改其他层。但实际上，项目中出现的实体越多，遵守起来就越困难。

一开始会出现太多的依赖关系，并且控制它们变得越来越困难。这意味着对整体架构的忽视（毕竟，洋葱是一个整体架构）。负载分配不正确，应用程序出现过载。此外，各层开始混合——隔离应用程序逻辑变得越来越困难。扩展应用程序变得越来越困难，依赖性使调试变得地狱，开发速度大大减慢。火上浇油的是严格的架构模式限制了开发人员的能力。如果您正在阅读本文，您可能已经遇到过这种情况。我们的项目也出现了同样的情况。

显然，在这种情况下，有必要削减单体架构，切换到另一种架构并引入更自由的模式。我们选择了 DDD，这似乎是一个显而易见的解决方案。 DDD （领域驱动设计，六边形架构） 是一种基于抽象构建的微服务（尽管它可以用作整体）架构。如果您只有使用分层架构的经验，那么作为一个粗略的示例，您可以想象相同的三层架构，其中不是与存储交互的层，而是与所有技术交互的层，并且还有具有抽象的单独层。抽象通常是 DDD 中的主要内容。这些抽象以及辅助工具和演示实体（模板、图表）与应用程序分离，因此架构如下所示：

heskagonal 架构相对于分层架构的主要优势是可扩展性。因为依赖关系更少，所以实现新特性、新参数和新功能要容易得多。

起初，这种结构对我来说完全不合逻辑，但是在切换到 DDD 的过程中，我发现它变得更容易编写，因为甚至从应用程序的最底层也完全删除了基础设施，并且有依赖性更少。每个实体甚至都出现了某种非理性的解脱和突然的行动自由。现在在我看来，这种方法比分层架构更符合逻辑。

但是你需要记住，如果项目中有 2-3 个实体，这样的架构就没有意义，因为 DDD 主要用作具有大量依赖项的应用程序中的微服务架构，这根本无法在具有 2-3 个实体的小型宠物项目。在某些地方，即使是简单的线性架构就足够了。一般来说，不必要地使用不同的技术和实践是不好的做法，除非您决定尝试学习。

P.S.你需要迷上 TGC：https://t.me/dmkjfss

以上是从分层架构到DDD。我的迁移和切割巨石的经历的详细内容。更多信息请关注PHP中文网其他相关文章！