近年来,微服务已经成为一种非常流行的构建软件的方法。微服务用于构建可伸缩、灵活的软件。然而,跨多团队随机构建微服务可能会带来很大的挫折和复杂性。不久前我还没有听说过领域驱动设计——DDD,但现在无论走到哪里似乎每个人都在谈论它。
在本文,我将从头开始构建一个在线酒店应用来一步步地探索DDD的各种概念。希望每实现一部分,对理解DDD会更容易。采用这种方法的原因是,每次我在阅读DDD资料时都很头疼。有这么多的概念,很宽泛和不清楚,不清楚什么是什么。如果你不知道为什么我在研究DDD时头疼,下面的图可能会让你认识到这一点。
从上面的图片可以看得出来,为什么Eric Evans在他的《领域驱动设计:解决软件核心的复杂性》要用500页来解释什么是领域驱动设计。如果你对学习DDD有兴趣可以阅读本书。
首先,我想指出的是,本文描述了我对DDD的理解,我在本文中展示的实现是基于我对go相关项目的经验得出的最佳实践。我们将创建的实现绝不是社区所接受的最佳实践。我还将在项目中以DDD方法命名文件夹,以使其易于理解,但我不确定这是否是我想要的代码框架的样子。基于此,我将创建另一个分支来修正代码结构,这个重构将在其他文章解释。
我在网上看到很多关于DDD和如何正确实现的激烈讨论。让我印象深刻的是,多数时候人们似乎忘记了DDD背后的目的,都以讨论一些小的实现细节而告终。我认为重要的是遵循Evan提出的方法,而不是命名为X或Y。
DDD是一个很大的领域,我们将主要关注它的实现,但在我们实现任何东西之前,我将对DDD中的一些概念做一个快速的概述。
什么是DDD?
领域驱动设计是在软件所属领域之后对软件进行结构化和建模的一种方法。这意味着必须首先考虑所编写的软件的领域。领域是软件将处理的主题或问题。软件的编写应该反映该领域。
DDD主张工程团队必须与主题专家(SME)交谈,他们是领域内的专家。这样做的原因是SME拥有关于领域的知识,这些知识应该反映在软件中。想想看,如果我要做一个股票交易平台,作为一名工程师,我对这个领域的了解够不够去做一个好的股票交易平台?如果我能和沃伦·巴菲特谈谈这个领域,这个平台可能会好得多。
代码中的架构也应该反映领域。当我们开始编写我们的酒店应用时,我们将体会到领域内涵。
Gopher的DDD之路
让我们开始学习如何实现DDD,在开始之前我将给你讲述一个Gopher和Dante的故事,他们想创建一个在线酒店应用。Dante知道如何写代码,但是对如何运营一个酒店一无所知。
在Dante决定开始创建酒店应用的那天,他遇到了一个问题,从哪里开始,如何开始?他出去散步,思考这个问题。在公交站标志前等待的时候,一个戴大礼帽的男人走近Dante说:
“看起来你好像在担心什么事情,年轻人,需要帮忙建一个酒店应用吗?”
Dante和大礼帽男一起散步,他们讨论了酒店以及如何经营。Dante问如何处理酒徒(drinker),大礼帽男纠正说是客户(Customer)不是酒徒(drinker)。大礼帽男还向Dante解释了酒店还需要一些东西来运作,比如顾客、员工、银行和供应商。
领域、模型、统一语言和子领域
我希望你们喜欢Dante的故事,我写它是有原因的。我们可以用这个故事来解释DDD中使用的一些概念,这些词如果没有上下文很难解释,比如一个短篇故事。
Dante和大礼帽男已经讨论了一个领域模型会话。大礼帽男作为该方面的专家而Dante作为工程师讨论了领域空间并找到了共同点。这样做是为了学习模型,模型是处理领域所需组件的抽象。当Dante和大礼帽男在讨论酒店,他们正是在讨论相关领域。该领域是软件运行的关注点,我将把酒店(Tavern)称为核心/根领域。
大礼帽男还指出,它不叫饮酒徒,而叫顾客。这说明了在SMO和开发人员之间找到一种通用语言是多么重要。如果不是项目中的每个人都有通用语言,那将会非常令人困惑。我们还得到了一些子领域,这是大礼帽男提到的酒店应用所需要的东西。子领域是一个单独的领域,用于解决根领域内的相关东西。
使用Go编写一个DDD应用-Entities(实体)和Value Object(值对象)
我们已经了解了酒店应用的相关东西,是时候编写酒店系统代码了。通过创建go module来配制本项目。
mkdir ddd-go
go mod init github.com/percybolmer/ddd-go
我们将创建一个domain目录,存放所有的子领域,但在实现领域之前,我们需要在根目录下创建另一个目录。出于说明的目的,我们将其命名为entity,因为它将保存DDD方法中所谓的实体。一个实体是一个结构体包含标志符,其状态可能会变,改变状态的意思是实体的值可以改变。
首先我们将创建两个实体,Person和Item。我喜欢将实体保存在一个单独的包中,以便它们可以被所有其他领域使用。
为了保持代码整洁,我喜欢小文件,并使文件夹结构易于浏览。因此,我建议创建两个文件,每个文件对应一个实体,并以实体命名。现在,仅仅包含结构体定义,稍后会添加一些其他逻辑。
为领域创建第一个实体
//entities包保存所有子领域共享的所有实体
package entity
import (
"github.com/google/uuid"
)
// Person 在所有领域中代表人
type Person struct {
// ID是实体的标识符,该ID为所有子领域共享
ID uuid.UUID `json:"id" bson:"id"`
//Name就是人的名字
Name string `json:"name" bson:"name"`
// 人的年龄
Age int `json:"age" name:"age"`
}
package entity
import "github.com/google/uuid"
// Item表示所有子领域的Item
type Item struct {
ID uuid.UUID `json:"id" bson:"id"`
Name string `json:"name" bson:"name"`
Description string `json:"description" bson:"description"`
}
ok,现在我们已经定义了一些实体并了解了什么是实体。一个结构体具有唯一标识符来引用,状态可变。
有些结构体是不可变的,不需要唯一标识符,这些结构体被称为值对象。所以结构体在创建后没有标识符和持久化值。值对象通常位于领域内,用于描述该领域中的某些方面。我们现在将创建一个值对象,它是Transaction,一旦事务被执行,它就不能改变状态。
在真实的应用程序中,通过ID跟踪事务是一个好主意,这里只是为了演示