通过披萨理解领域驱动设计

微服务架构的出现已有一段时间了，它是为了应对现代应用开发中面临的挑战而提出的。微服务架构的核心是围绕领域驱动设计原则构建的。

让我们了解什么是领域驱动设计以及它为软件开发提供的指导方针。

领域驱动设计（DDD）

领域驱动设计是微服务背后的理念。它并不提供实现软件架构的实用方法，而是侧重于一些有助于构建可维护软件的指导原则。我们将以现实世界中的披萨店为例来理解这些概念。

让我们看几个术语。

领域

简单来说，它是我们构建应用程序的主题。应用程序中的每个组件都是根据领域需求进行选择、编程和部署的。

我们店的主打产品是披萨，一切都围绕着披萨来打造。厨师、食材、菜单、广告牌等等。

语境

围绕领域的环境。在我们的案例中，商店成为了我们的环境。满足领域相关需求所需的一切都被封装在环境之中。

模型

领域的构建块。组合起来解决问题的不同部分。在我们的案例中，不同角色的人、食材、披萨、家具、机器等等都成为了我们的模型。

无处不在的语言

在谈论上下文中的任何事物时所使用的语言和术语。

有界上下文

一个子系统或职责分工。店里的每位员工都有各自的职责。厨师和收银员不太可能会时不时地互换角色，也不需要深入了解彼此的工作。

现在我们已经了解了术语，让我们来看看原理。

围绕业务领域对软件进行建模

业务领域构成了所有架构决策的基础。业务模型和软件组件应该相互映射。无论开发人员还是业务主管使用哪个术语，其含义都是一样的。最终的软件反映了业务的运作方式。

在我们的店里，如果店主使用“小”、“中”、“大”这些词语，建议收银员也使用相同的词语，而不是用英寸来描述披萨的大小。这样可以让双方更容易理解。

软件在有界上下文中演进

有界上下文描述了子系统需要在其范围内演进和思考的边界。它不应该担心其他有界上下文如何变化，也不应该试图为它们解决问题。

披萨外送无需厨师的同意就能不断发展。同样，外送员也不会规定厨房需要使用哪些食材。他们会自行解决问题，并独立改进工作。

一个子域不会破坏另一个子域的功能。

通过优先考虑领域专家的意见来构建领域

开发团队不需要对业务需求一无所知。他们应该先从业务角度理解需求，然后再考虑技术领域。

领域专家负责细化需求。他们负责捕捉领域需求，并作为解决任何歧义的联络点。领域专家不一定非得是非技术人员。他们可以是任何对该领域进行过深入研究并拥有相关工作经验的人。

当我们的商店需要广告牌时，店主会去找营销专家和设计师，而不是自己决定横幅的设计。他也不会让实际的横幅制作者来做决定。

让我们看看遵循领域驱动设计的好处

DDD 并非万能灵丹妙药。过分地践行它往往会适得其反。在某些情况下，你应该在使用它之前进行“双重思考”：

感谢阅读。希望本文能帮助你深入了解领域驱动设计。

您可以在这里找到更多关于我的信息，通过Twitter
与我联系以获取更多内容。