NodeJS的DDD与CRUD对比案例 - Khalil Stemmler

栏目: Node.js · 发布时间: 4年前

内容简介：当你开始一个新的Node.js项目时，你先从什么开始？您是从数据库架构开始的吗？你是从RESTful API开始的吗？

当你开始一个新的Node.js项目时，你先从什么开始？

您是从数据库架构开始的吗？

你是从RESTful API开始的吗？

你是从Model开始的吗？

REST-first Design(REST优先设计)是一个专门术语，我一直用它来描述 Domain-Driven Design (领域驱动设计)项目与REST-first CRUD项目在代码级别上的区别。

REST代表“Representational State Transfer”，这是一种使用HTTP在Web上设计API的架构风格。

在本文中，我将解释RREST-first Design的代码库是什么样的，它的必要性以及它与Domain-Driven Designed项目的区别。

命令范式

您可能已经在生活中编写了许多命令式代码，这通常是我们开始编程时开始学习的第一件事。命令式代码主要关注“我们如何”做某事。我们需要非常清楚地了解程序的状态如何变化。

例如用命令式实现：找到数组中的最大数量：

<b>const</b> numbers = [1,2,3,4,5];
let max = -1;
<b>for</b> (let i = 0; i < numbers.length; i++) {
  <b>if</b> (numbers[i] > max) {   
    max = numbers[i] 
  }
}

因为命令式编程要求您指定确切的命令来指定程序状态如何更改，在本例中，我们：

  • 有一个数字列表
  • 从0开始创建一个for循环
  • 将i增加到numbers.length
  • 如果当前索引处的数字大于最大值，那么我们将其设置为最大值

这就是我们用命令式代码做的事情。我们定义“如何”。REST-first设计通常是自然的命令式。

声明范式

声明性编程更关注“什么”。

因此，声明性代码更加“冗长”，并且为了表达性而抽象出很多细节。

让我们看一下同样的例子。

<b>const</b> numbers = [1,2,3,4,5]
<b>const</b> max = numbers.reduce((a,b) => Math.max(a,b))

“这两个例子中的哪一个会让非 程序员 更快理解？”（当然是后者），在此示例中，语言更好地描述了“什么”而不是命令式等效？这就是声明性编程的美妙之处。代码更易读，程序意图更容易理解（如果操作被恰当地命名）。

声明式样式代码是使用领域驱动设计设计软件的主要好处之一。

REST优先设计

当我们构建RESTful应用程序时，我们倾向于更多地考虑从以下任一方面设计应用程序：

  • 数据库
  • API调用

因此，我们倾向于将大部分业务逻辑放在控制器或服务中。

你可能还记得Bob叔叔的“清洁架构”，对于控制器而言，这绝对是禁忌。如果您阅读他的同名书籍，您可能会想起将所有域逻辑置于服务中的潜在服务导向谬误（提示： 贫血领域模型 ）。

但如果是下面情况：

  • 我们想要快速获得一些东西
  • 我们使用了一个框架，如 Nest.js
  • 我们想要回应原型应用
  • 我们正在开发小型应用程序
  • 我们正在研究 硬件软件问题中的 ＃1或＃2  问题

它足以满足大量项目的需求！但是，对于具有复杂业务规则和策略的复杂域，随着时间的推移，这有可能变得非常难以改变和扩展。

在REST优先的CRUD应用程序中，我们几乎只编写命令式代码来满足业务用例 。我们来看看它的样子。

假设我们正在开发一个Customers可以租用的应用程序Movies。使用 Express.js 和 Sequelize ORM 设计REST优先，我的代码可能如下所示： 

<b>class</b> MovieController {
  <b>public</b> async rentMovie (movieId: string, customerId: string) {
    <font><i>// Sequelize ORM models</i></font><font>
    <b>const</b> { Movie, Customer, RentedMovie, CustomerCharge } = <b>this</b>.models;

    </font><font><i>// Get the raw orm records from Sequelize</i></font><font>
    <b>const</b> movie = await Movie.findOne({ where: { movie_id: movieId }});
    <b>const</b> customer = await Customer.findOne({ where: { customer_id: customerId }});

    </font><font><i>// 401 error if not found</i></font><font>
    <b>if</b> (!!movie === false) {
      <b>return</b> <b>this</b>.notFound('Movie not found')
    }

    </font><font><i>// 401 error if not found</i></font><font>
    <b>if</b> (!!customer === false) {
      <b>return</b> <b>this</b>.notFound('Customer not found')
    }

    </font><font><i>// Create a record which signified a movie was rented</i></font><font>
    await RentedMovie.create({
      customer_id: customerId,
      movie_id: movieId
    });

    </font><font><i>// Create a charge for this customer.</i></font><font>
      await CustomerCharge.create({
      amount: movie.rentPrice
    })

    <b>return</b> <b>this</b>.ok();
  }
}
</font>

在这个代码示例中，我们传入一个 movieId和一个 customerId，然后拉出我们知道我们将需要使用的相应Sequelize模型。我们进行快速的空检查，如果返回两个模型实例，我们将创建一个RentedMovie和一个CustomerCharge。

这是快速而又脏的，它向您展示了我们能够以多快的速度完成并运行REST优先 。

但是，一旦我们添加业务规则，事情就开始变得具有挑战性。让我们为此添加一些约束。考虑到以下Customer情况不允许租借电影：

A）一次租用最多的电影数量（但这是可配置的）

B）有未支付的余额。

我们究竟能如何强制执行此业务逻辑？一种原始的方法是直接在我们MovieController的purchaseMovie方法中强制执行它。

<b>class</b> MovieController <b>extends</b> BaseController {
  constructor (models) {
    <b>super</b>();
    <b>this</b>.models = models;
  }
  <b>public</b> async rentMovie () {
    <b>const</b> { req } = <b>this</b>;
    <b>const</b> { movieId } = req.params['movie'];
    <b>const</b> { customerId } = req.params['customer'];

    <font><i>// We need to pull out one more model,</i></font><font>
    </font><font><i>// CustomerPayment</i></font><font>
    <b>const</b> { 
      Movie, 
      Customer, 
      RentedMovie, 
      CustomerCharge, 
      CustomerPayment 
    } = <b>this</b>.models;

    <b>const</b> movie = await Movie.findOne({ where: { movie_id: movieId }});
    <b>const</b> customer = await Customer.findOne({ where: { customer_id: customerId }});

    <b>if</b> (!!movie === false) {
      <b>return</b> <b>this</b>.notFound('Movie not found')
    }

    <b>if</b> (!!customer === false) {
      <b>return</b> <b>this</b>.notFound('Customer not found')
    }

    </font><font><i>// Get the number of movies that this user has rented</i></font><font>
    <b>const</b> rentedMovies = await RentedMovie.findAll({ customer_id: customerId });
    <b>const</b> numberRentedMovies = rentedMovies.length;

    </font><font><i>// Enforce the rule</i></font><font>
    <b>if</b> (numberRentedMovies >= 3) {
      <b>return</b> <b>this</b>.fail('Customer already has the maxiumum number of rented movies');
    }

    </font><font><i>// Get all the charges and payments so that we can </i></font><font>
    </font><font><i>// determine if the user still owes money</i></font><font>
    <b>const</b> charges = await CustomerCharge.findAll({ customer_id: customerId });
    <b>const</b> payments = await CustomerPayment.findAll({ customer_id: customerId });

    <b>const</b> chargeDollars = charges.reduce((previousCharge, nextCharge) => {
      <b>return</b> previousCharge.amount + nextCharge.amount;
    });

    <b>const</b> paymentDollars = payments.reduce((previousPayment, nextPayment) => {
      <b>return</b> previousPayment.amount + nextPayment.amount;
    })

    </font><font><i>// Enforce the second business rule</i></font><font>
    <b>if</b> (chargeDollars > paymentDollars) {
      <b>return</b> <b>this</b>.fail('Customer has outstanding balance unpaid');
    }

    </font><font><i>// If all else is good, we can continue</i></font><font>
    await RentedMovie.create({
      customer_id: customerId,
      movie_id: movieId
    });
    
    await CustomerCharge.create({
      amount: movie.rentPrice
    })

    <b>return</b> <b>this</b>.ok();
  }
}
</font>

有几个缺点:

1. 缺乏封装

在开发与这些规则相交的新功能时，另一位开发人员可能会无意中绕过我们的域逻辑和业务规则，因为它存在一个不应该存在的地方。

我们可以轻松地将此域逻辑移动到服务。这将是一个小改进，但实际上，它只是重新定位问题发生的地方，因为其他开发人员仍然能够在单独的模块中编写我们刚刚编写的代码，并规避业务规则。

有更多的理由。如果您想更多地了解服务如何失控， 请阅读此内容 。

需要有一个地方来决定一个Customer人可以做什么行动，那就是领域模型。

2. 缺乏可发现性

当您第一次查看类及其方法时，应该准确地向您描述该类的功能和限制。当我们共同定位Customer基础设施问题（控制器）中的功能和规则时，我们会失去一些可以发现的Customer功能以及何时可以执行此功能。

3. 缺乏灵活性

您如果希望您的应用程序是多平台的，与旧系统集成或将您的应用程序作为桌面应用程序提供，我们需要 确保没有任何业务逻辑存在于控制器中，而是驻留在域层 。

CRUD优先设计是一种“事务脚本”方法

在企业软件领域，Martin Fowler称之为事务脚本，事务脚本方法是我们用来编写所有后端代码的单一方法。REST-first Design（通常是设计）是一个事务脚本。

我们如何改进？我们使用领域模型。

DDD

在域建模中，主要好处之一是用于指定业务规则的声明性语言变得如此富有表现力，以至于我们没有时间添加新的功能和规则。这也使得我们的业务逻辑更具有可读性。

如果我们采用前面的例子并通过DDD镜头观察它，控制器代码可能看起来更像这样：

<b>class</b> MovieController <b>extends</b> BaseController {
  <b>private</b> movieRepo: IMovieRepo;
  <b>private</b> customerRepo: ICustomerRepo;
  
  constructor (movieRepo: IMovieRepo, customerRepo: ICustomerRepo) {
    <b>super</b>();
    <b>this</b>.movieRepo = movieRepo;
    <b>this</b>.customerRepo = customerRepo;
  }

  <b>public</b> async rentMovie () {
    <b>const</b> { req, movieRepo, customerRepo } = <b>this</b>;
    <b>const</b> { movieId } = req.params['movie'];
    <b>const</b> { customerId } = req.params['customer'];

    <b>const</b> movie: Movie = await movieRepo.findById(movieId);
    <b>const</b> customer: Customer = await customerRepo.findById(customerId);

    <b>if</b> (!!movie === false) {
      <b>return</b> <b>this</b>.fail('Movie not found')
    }

    <b>if</b> (!!customer === false) {
      <b>return</b> <b>this</b>.fail('Customer not found')
    }

    <font><i>// The declarative magic happens here.</i></font><font>
    <b>const</b> rentMovieResult: Result<Customer> = customer.rentMovie(movie);

    <b>if</b> (rentMovieResult.isFailure) {
      <b>return</b> <b>this</b>.fail(rentMovieResult.error)
    } <b>else</b> {
      </font><font><i>// if we were using the Unit of Work pattern, we wouldn't </i></font><font>
      </font><font><i>// need to manually save the customer at the end of the request.</i></font><font>
      await customerRepo.save(customer);
      <b>return</b> <b>this</b>.ok();
    }
  }
}
</font>

我们不再需要担心：

  • 如果Customer有超过最大租借电影数量
  • 如果Customer已经支付了他们的账单
  • Customer在他们租借电影后开帐单。

这是DDD 的声明本质。如何完成它是抽象的，但是有效使用的无处不在的语言描述了允许域对象做什么以及何时做什么。


以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍
深入浅出HTML与CSS、XHTML

深入浅出HTML与CSS、XHTML

[美] 弗里曼 Freeman.E. / 东南大学出版社 / 2006-5 / 98.00元

《深入浅出HTML与CSS XHTML》(影印版)能让你避免认为Web-safe颜色还是紧要问题的尴尬，以及不明智地把标记放入你的页面。最大的好处是，你将毫无睡意地学习HTML、XHTML 和CSS。如果你曾经读过深入浅出（Head First）系列图书中的任一本，就会知道书中展现的是什么：一个按人脑思维方式设计的丰富的可视化学习模式。《深入浅出HTML与CSS XHTML》(影印版)的编写采用了......一起来看看 《深入浅出HTML与CSS、XHTML》 这本书的介绍吧!

码农工具
JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具

  • New
  • 文章
  • 话题
  • 教程
    • 关注 码农网 公众号
    版权所有，保留一切权利！© 2018-2024 码农网 粤ICP备17054400号-3