nextjs clean architecture

Next.js中的清洁体系结构

此存储库是如何在Next.js中实现干净体系结构的一个示例。有一个视频教程贯穿该项目。单击图像以在YouTube上查看：

您只需运行npm install和npm run dev即可运行项目。

干净的体系结构

笔记

？我绘制了原始清洁架构图的简化版本。我以一种对我来说更有意义的方式简化了它，并且更容易理解。我希望它也对您有所帮助。

我强烈建议您阅读Bob叔叔的原始文章，如果您是您第一次听到有关干净建筑的消息，但我会在下面为您总结一下。

干净的体系结构是一组规则，可以帮助我们以更易于维护和测试的方式构建应用程序，并且它们的代码库是可以预测的。无论他们的技术背景和编程语言偏好如何，这就像开发人员理解的通用语言。

干净的体系结构和类似/衍生的体系结构都具有相同的目标 -关注点的分离。他们引入将类似代码捆绑在一起的层。 “分层”有助于我们在代码库中实现重要方面：

• 独立于UI-业务逻辑与正在使用的UI框架（在这种情况下为Next.js）。可以在CLI应用程序中使用相同的系统，而无需更改业务逻辑或规则。
• 独立于数据库- 数据库实现/操作是在自己的层中隔离的，因此应用程序的其余部分不在乎使用哪个数据库，而是使用模型进行通信。
• 独立于框架- 业务规则和逻辑根本对外界一无所知。他们接收使用普通JavaScript定义的数据，使用普通的JavaScript，服务和存储库来定义自己的逻辑和功能。这使我们能够将框架用作工具，而不必将我们的系统“塑造”到其实现和局限性中。如果我们在应用程序中使用路由处理程序，并且想重构其中一些用于服务器操作，那么我们需要做的就是仅在服务器操作中调用特定的控制器而不是路由处理程序，但是核心业务逻辑保持不变。
• 可测试- 可以轻松测试业务逻辑和规则，因为它不取决于UI框架，数据库，Web服务器或构建我们系统的任何其他外部元素。

干净的体系结构通过定义依赖性层次结构来实现这一目标 - 图层仅取决于下面的层，但不取决于上面的层。

项目结构（仅重要的位）

• app框架和驱动程序层- 基本上所有Next.js（页面，服务器操作，组件，样式等）或任何“消耗”应用程序的逻辑的内容
• di依赖注入 - 我们设置DI容器和模块的文件夹
• drizzle - 所有DB-初始化数据库客户端，定义模式，迁移
• src系统的“根”
  • application -应用程序层- 持有用例和界面，用于存储库和服务
  • entities -实体层- 保存模型和自定义错误
  • infrastructure -基础架构层- 持有存储库和服务的实现，并从application中提取界面
  • interface-adapters -接口适配器层- 保存控制器，这些控制器是系统的切入点（在框架和驱动程序中用于与系统交互）
• tests - 单位测试现场 - unit文件夹的结构与src匹配
• .eslintrc.json eslint-plugin-boundaries​
• vitest.config.ts注意@别名的定义方式！

层解释

• 框架和驱动程序：保留所有UI框架功能，以及与系统相互作用的所有其他功能（例如AWS lambdas，Stripe Webhooks等...）。在这种情况下，这是Next.js路由处理程序，服务器操作，组件（服务器和客户端），页面，设计系统等...
  • 该层仅应使用控制器，模型和错误，并且不得使用用例，存储库和服务。
• 接口适配器：定义控制器：
  • 控制器将输入传递给特定用例之前，请执行身份验证检查和输入验证。
  • 控制者协调用例。他们没有实施任何逻辑，而是使用用例定义整个操作。
  • 较深层的错误被起泡并在使用控制器的地方处理。
  • 控制者使用演示者将数据转换为对UI友好的格式，然后将其返回“消费者”。这有助于我们将JavaScript减少到客户端（可转换数据的逻辑和库），有助于防止泄漏任何敏感属性，例如电子邮件或哈希密码，还可以帮助我们减少发送给客户端的数据量。
• 应用：业务逻辑居住的地方。有时称为核心。该层定义了服务和存储库的用例和接口。
  • 用例：
    • 表示单个操作，例如“创建todo”或“ sign in”或“ toggle todo”。
    • 接受预先验证的输入（来自控制器）并处理授权检查。
    • 使用存储库和服务访问数据源并与外部系统进行通信。
    • 用例不应使用其他用例。那是代码的气味。这意味着用例有多件事，应分解为多种用例。
  • 存储库和服务的接口：
    • 这些是在此层中定义的，因为我们想打破其工具和框架的依赖性（数据库驱动程序，电子邮件服务等），因此我们将在基础架构层中实现它们。
    • 由于接口生活在该层中，因此用例（以及上层层）可以通过依赖注入访问它们。
    • 依赖注入使我们可以将定义（接口）与实现（类）分开，并将它们放在单独的层（基础架构）中，但仍然允许使用它们。
• 实体：定义模型和错误的地方。
  • 型号：
    • 使用普通JavaScript定义“域”数据形状，而无需使用“数据库”技术。
    • 模型并不总是与数据库息息相关 - 发送电子邮件需要外部电子邮件服务，而不是数据库，但是我们仍然需要具有数据形状，以帮助其他层交流“发送电子邮件”。
    • 模型还定义了自己的验证规则，该规则称为“企业业务规则”。通常不会更改的规则，或者当某些东西更改时（页面导航，安全等）时最不可能更改的规则。一个示例是一个User模型，它定义了一个用户名字段，该字段必须至少为6个字符，而不包括特殊字符。
  • 错误：
    • 我们想要自己的错误，因为我们不想冒出特定于数据库的错误或特定于库或框架的任何类型的错误。
    • 我们catch来自其他库（例如毛毛雨）的错误，并将这些错误转换为我们自己的错误。
    • 这就是我们可以使核心独立于任何框架，库和技术的方式 - 干净体系结构的最重要方面之一。
• 基础架构：在哪里定义了存储库和服务。
  • 该层从应用程序层中拉出存储库和服务的接口，并将其实现在自己的类中。
  • 存储库是我们实施数据库操作的方式。它们是揭示执行单个数据库操作的方法的类 - 例如getTodo ， createTodo或updateTodo 。这意味着我们仅在这些类中使用数据库库 /驱动程序。他们没有执行任何数据验证，只需对数据库执行查询和突变，然后投掷我们的自定义定义错误或返回结果。
  • 服务是整个应用程序中使用的共享服务 - 例如身份验证服务，电子邮件服务，或实施外部系统（例如Stripe（创建付款，验证收据等）...）。这些服务还使用并取决于其他框架和库。这就是为什么他们的实施与存储库一起保存在这里的原因。
  • 由于我们不希望任何一层取决于这一层（并且具有传递性取决于数据库和所有服务），因此我们使用依赖性反转原理。这使我们仅依赖于应用程序层中定义的接口，而不是基础结构层中的实现。我们使用像ioctopus这样的控制库的反转来抽象接口背后的实现，并在需要时“注入”它。我们在di目录中创建抽象。我们将存储库，服务，控制器和用例“绑定”到符号，然后在需要实际实施时使用这些符号“解决”它们。这就是我们可以使用实现的方式，而无需明确依赖它（导入）。

常问问题

提示

如果您有一个常见问题解答未介绍的问题，请随时在此存储库中打开问题，或者加入我的Discord Server并在那里开始对话。

干净的体系结构 /此实现无服务器友好吗？我可以将其部署到Vercel吗？

是的！您可以将其与页面路由器，应用程序路由器，中间件，API处理程序，服务器操作等一起使用！通常，使用iNversify.js库在JavaScript项目中实现依赖项注入，这与节点除外的其他运行时间不兼容。该项目实现了IOCTOPUS，这是一个简单的IOC容器，不依赖reflect-metadata并在所有运行时起作用。

创建下一个项目时，我应该立即开始实施干净的体系结构吗？

我说不。如果您正在启动一个全新的项目，我建议您专注于尽可能快地实现MVP状态（因此您可以验证您的想法 /查看项目是否有未来）。当事情开始变得严重时（更多功能开始实施，您的用户群会体验到显着的增长，或者您正在登上项目中的其他开发人员），这就是您想花一些时间来调整此体系结构（或任何此事的任何体系结构）。

如果您已经在项目中的杂草深处，那么您（和您的团队）可以从下一个冲刺开始逐步进行重构。在这种情况下，您已经编写了代码，您只需要对其进行重新组织，然后可以部分地进行该代码，以路由处理程序进行路由处理程序，通过服务器操作，服务器操作。顺便说一句，我说“您只需要重新组织一点” ，但它远非如此简单。当您计划重构时，请务必考虑“出错”。并花一些时间进行编写测试！

这看起来像是过度工程的，并且使特征开发变得复杂。

如果您不花超过3分钟的时间考虑一下，那么是的，它看起来确实是过度工程的。但是，如果这样做，您将意识到架构=学科。该体系结构是开发人员之间的合同，可以定义去哪里。它实际上简化了功能开发，因为它使代码库可预测，并且为您做出这些决定。

如果每个从事它的开发人员都会在最方便的地方写代码，那么您将无法可持续发展一个项目。代码库将变成与之合作的噩梦，这就是您会感到真正复杂的功能开发过程的时候。为了与之抗争，最终您将放下一些规则。这些规则将随着您的团队面对并解决新问题而增长。将所有这些规则放在文档中，并且有您自己的架构定义。您仍然实现某种建筑，您刚刚非常缓慢而痛苦地达到了这一点。

干净的体系结构为您提供了经过测试的快捷方式和预定义的体系结构。是的，可以肯定的是，您确实需要学习所有这些，但是您一生都需要一次，然后将以后使用的任何语言或框架应用原则。

我应该在所有项目中应用干净的体系结构吗？

不。如果您不希望该项目在功能数量，用户数量或从事该项目的开发人员数量上都增长。

清洁建筑的其他类似架构是什么？

正如我在Readme顶部提到的原始博客文章中提到的那样，您得到了：

• Alistair Cockburn的六角形建筑（又名港口和适配器）
• Jeffrey Palermo的洋葱建筑
• 鲍勃叔叔的尖叫建筑（干净建筑背后的同一个人）
• 还有更多（查看原始博客文章）