メインコンテンツまでスキップ

「DDD」タグの記事が1件件あります

全てのタグを見る

· 約4分
wen

What

本文是对谷歌Write Change-Resilient Code with Domain Objects的翻译。

原作者: Amy Fu

译文

尽管产品的需求经常变化,但其基本理念通常变化缓慢。由此得出一个有趣的结论:如果我们编写的代码符合产品的基本理念,那么它在未来产品变更中存活的可能性就会更高。

领域对象是我们代码中的基本构建块(如类和接口),它们与产品的基本概念相匹配。我们不是编写代码来匹配产品需求的期望行为(“将文本设置为白色”),而是匹配其底层概念(“文本颜色设置”)。

例如,假设你是披萨团队的一员,该团队向饥饿的谷歌员工出售美味新鲜的披萨。由于需求量大,你们团队决定增加送货服务。

如果没有域对象,最快的送比萨途径就是直接创建一个 deliverPizza 方法:

公共类 DeliveryService

公开的 void 方法 deliverPizza(List pizzas):...},

}

虽然这种做法在初期效果不错,但如果 gPizza 将其产品线扩展到其他食品上会怎样呢? 你可以添加一个新的方法:

公开的 void 方法 deliverWithDrinks(List pizzas, List drinks) ...},

但是随着你需要的功能越来越多(比如零食、甜食等),你将不得不不断添加更多的方法。你该如何修改初始实现以避免这种持续的维护负担呢?

你可以添加一个表示产品理念的领域对象,而不是其需求:

  • 用例是指帮助产品满足其业务需求的特定行为。

  • 一个域对象代表了由多个相似用例共享的通用概念。

为了确定合适的领域对象,请问自己:

  • 1.该产品支持哪些相关的使用场景,我们未来计划支持哪些方面?

A:gPizza 打算开始送披萨,将来还会送饮料和零食等其他产品。

    1. 这些用例有哪些共同点?

A:gPizza 想要把顾客订购的食物送达。

    1. 我们可以用什么域对象来表示这个通用概念呢?

A:这个领域对象是食品订单。我们可以将用例封装到一个 FoodOrder 类中。

领域对象是一种有用的抽象,但要避免选择过于通用的对象,因为在提高可维护性和更复杂、更模糊的代码之间存在权衡。通常,目标是仅支持计划中的用例,而不是所有可能的用例(参见 YAGNI 原则)。

// GOOD: It's clear what we're delivering.
public void deliver(FoodOrder order) {}