Go中的微服务-领域驱动设计和项目布局

什么是领域驱动设计？

根据Martin Fowler的说法。

领域驱动设计是一种软件开发的方法，它将开发的中心放在对一个领域的过程和规则有丰富理解的领域模型的编程上

这不是一个新的概念，事实上领域驱动设计是Eric Evans在近20年前创造的一个术语（蓝皮书在2003年出版）。然而，近年来，由于微服务的流行，以及这些微服务是如何被设计成以最佳方式做一件事的，它变得更加相关。

然而，领域驱动设计有以下几个方面的注意事项。

• 它不容易实现，而且需要更多的工作，特别是领域层的隔离和封装，以保持主模型尽可能的纯净。
• 它被推荐用于大型和复杂的系统，因为它需要有领域专家与负责编写软件的团队合作工作。

推荐涵盖领域驱动设计的书籍，按照我建议的顺序排列。

• 领域驱动设计精解
• 领域驱动设计。攻克软件核心的复杂性
• 实施领域驱动设计

了解 "待办 "领域

这篇文章使用的代码可以在Github上找到，请随意使用。

我们的 "To Do微服务 "将实现一个To Do域，它由以下规则组成。

• Task (s)是需要在一段时间内完成的活动，它们有一个优先级，可以进行分类。
  • 任务需要一个描述。
  • 其他任务可以被定义为前提条件。
• Period of Time 是一个任务开始或完成的时间点。
  • 它由一个开始日期和一个到期日期组成。
  • 这个值在任务上是不需要的。
  • 开始日期是 "小于 "到期日期。
• Priority 表示一项任务的重要性。
  • 有四个优先级。No Priority,Low Priority,Medium Priority 和High Priority 。
  • 默认的优先级是：No Priority 。
• Category 是一个人类可读的值，用于组织任务。
  • 值在所有中是唯一的。

项目布局

Go不强制执行任何项目结构或项目布局，没有具体的准则来选择如何组织我们的项目，通常最常见的答案是使用扁平结构，这对小项目来说确实有效，然而在处理真正复杂的系统时，这可能无法大规模地发挥作用。

与Go类似，领域驱动设计并不强制执行任何项目结构或项目布局，相反，它定义了我们必须遵循的概念，以便在负责执行的团队和领域专家之间进行适当的沟通。

很明显，我们需要别的东西...

这是另一个概念出现的地方。 六边形结构，唯一的目的是创建一个松散耦合的应用程序，可以通过端口和适配器进行互连。定义这些端口和适配器的目的是让组件之间通过具体的协议进行通信，在Go的世界里，我们可以把它们定义为接口类型。

在Go中，如果我们把所有东西放在一起，我们可以定义一个项目布局，其中包括一个 internal/包，其结构如下。

这是我喜欢在复杂的项目中遵循的结构，每个包被描述为以下内容。

• internal/ 定义了所有的领域类型和领域逻辑，所有的业务逻辑都应该尽可能地在这里定义。
  • internal/datastore 是一个占位符值，它的意思是代表存储库，它的字面意思应该是我们计划使用的数据存储的名称，如 或 。internal/postgresql internal/mongodb
  • internal/api 表示访问我们服务的公开方式，即我们用来向外界公开我们的API的方法，例如： 或 。internal/rest internal/grpc
  • internal/service 定义了所有的用例，在某些情况下定义了领域逻辑，意味着将数据存储和api连接在一起。

总结

回顾一下，这是这个系列的开始，我将继续发布更多的内容，详细描述如何处理构建微服务所需的所有变化，这其中包括。测试、授权、配置和可观察性。