该博客解释了可用于设计反应式系统的领域驱动设计的技术和构建块。

领域驱动设计是一种架构方法，专注于创建解决大型复杂问题的软件。 “谁能解决这个问题？”以及“他们将遵循什么流程？”稍后会讨论各个方面。

领域驱动设计在设计的早期就解决了核心问题，并帮助您构建解决方案（即识别实体、值对象、存储库、领域/应用程序/基础设施服务、有界上下文、规范等）

 目标

  • 通过将主要关注点放在领域和领域逻辑上来设计不断发展的模型。用户应用程序的主题领域是软件的领域。
  • DDD 的关键目标之一是基于领域专家易于理解的不断发展的模型创建软件实现。因此DDD为领域专家和软件开发人员之间提供了有效的沟通渠道。
  • 将大型复杂系统分解为较小的部分或子域。在一个连贯的模型中构建大型复杂系统可能很困难。

DDD 的准则与响应式架构更加兼容。例如，将大型系统分解为子域或更小的部分可以帮助我们确定边界。反应式微服务具有类似的目标，即它们需要沿着清晰的边界进行分离。
每个微服务都必须有明确定义的 API 和一组特定的职责。如果我们不知道微服务的职责，那么设计和构建它就会很困难。
DDD 提供了一组准则和技术，用于将较大的域分解为较小的域并定义清晰的边界。反应式框架 Lagom 是基于 DDD 构建的。然而，DDD和Reactive Architecture可以独立存在。

 什么是域？

领域是知识、影响力或活动的领域。在软件的上下文中，它指的是我们正在建模的业务或想法。了解该领域的人是领域专家。

如果您正在构建零售软件，那么您的领域将是零售，销售助理、收银员、客户服务代表、商店经理、库存经理、采购员等将是领域专家。这些人可能有也可能没有软件方面的专业知识。

DDD 的目的是构建领域专家理解的模型。这里的模型代表了对可以作为软件系统实现的领域的理解。领域模型也可以实现为图表或文档。
领域模型的软件应该以反映模型的方式实现。

domain

 无处不在的语言

在 DDD 中，软件开发人员和领域专家之间的沟通需要一种通用语言，称为通用语言。
通用语言中的单词起源于领域，来自领域专家以及在领域模型中使用的单词，并最终在软件中使用。应避免将软件术语引入该领域。
每当需要引入一个词时，软件开发人员和领域专家应该进行对话，以查找该领域中是否已经存在这样的词。

例如，如果我们开始使用数据库、事件总线、实体等技术术语，我们的领域专家可能会迷失方向。他们知道订单、付款、商品、发票、库存、客户等词语。这些词语是在零售店工作的人可以理解的。

通用语言使软件开发人员和领域专家之间的交流能够在不使用软件术语的情况下就领域模型和软件系统进行对话。

#scala #领域驱动设计 #反应式架构 #反应式系统 #ddd