Question

我最近一直在研究领域驱动的设计，必须说这种类型的架构设计在我体内激发了一些东西。当我尝试将其概念应用于Go项目时，遇到了一些障碍。以下是一些示例方法，但是我不确定该使用哪种方法。

项目结构摘录：

├── api/
├── cmd/
├── internal/
|   ├── base/
|   |   ├── eid.go
|   |   ├── entity.go
|   |   └── value_object.go
|   ├── modules/
|   |   ├── realm/
|   |   |   ├── api/
|   |   |   ├── domain/
|   |   |   |   ├── realm/
|   |   |   |   |   ├── service/
|   |   |   |   |   ├── friendly_name.go
|   |   |   |   |   ├── realm.go
|   |   |   |   |   └── realm_test.go
|   |   |   |   └── other_subdomain/
|   |   |   └── repository/
|   |   |       ├── inmem/
|   |   |       └── postgres/

所有方法的共同点：

package realm // import "git.int.xxxx.no/go/xxxx/internal/modules/realm/domain/realm"

// base contains common elements used by all modules
import "git.int.xxxx.no/go/xxxx/internal/base"

方法1：

type Realm struct {
   base.Entity

   FriendlyName FriendlyName
}

type CreateRealmParams struct {
    FriendlyName string
}

func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) {
   var err error
   var r = new(Realm)

   r.Entity = base.NewEntity(id)
   r.FriendlyName, err = NewFriendlyName(params.FriendlyName)

   return r, err
}

type FriendlyName struct {
    value string
}

var ErrInvalidFriendlyName = errors.New("invalid friendly name")

func (n FriendlyName) String() string { return n.value }

func NewFriendlyName(input string) (FriendlyName, error) {
    if input == "" {
        return ErrInvalidFriendlyName
    }
    // perhaps some regexp rule here...

    return FriendlyName{value: input}, nil
}

使用这种方法，我认为从长远来看将有很多重复的代码，但是至少，根据DDD的要求，FriendlyName值对象是不可变的，并且可以附加更多方法。

方法2：

type Realm struct {
    base.Entity

    FriendlyName string
}

type CreateRealmParams struct {
    FriendlyName string
}

func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) {
    var err error

    if err = validateFriendlyName(params.FriendlyName); err != nil {
        return nil, err
    }

    entity := base.NewEntity(id)

    return &Realm{
        Entity: entity,
        FriendlyName: params.FriendlyName,
    }, nil
}

除了很多示例缺少验证之外，这肯定是我在其中遇到的最常见的示例。

方法3：

type Realm struct {
    base.Entity

    friendlyName string
}

type CreateRealmParams struct {
    FriendlyName string
}

func CreateRealm(id base.EID, params *CreateRealmParams) (*Realm, error) {
    var err error

    if err = validateFriendlyName(friendlyName); err != nil {
        return nil, err
    }

    entity := base.NewEntity(id)

    return &Realm{
        Entity: entity,
        friendlyName: friendlyName,
    }, nil
}

func (r *Realm) FriendlyName() string { return r.friendlyName }
func (r *Realm) SetFriendlyName(input string) error {
    if err := validateFriendlyName(input); err != nil {
        return err
    }
    r.friendlyName = input
    return nil
}

这里友好名称类型只是一个字符串，但不可变。这种结构让我想起了Java代码... 查找领域时，存储库层是否应使用域模型中的setter方法来构建领域聚合？我尝试将DTO实现放置在与领域聚合进行编码/从领域聚合进行编码/解码的同一个包（dto_sql.go）中，但是将这种关注放在域包中感觉有点不对。

如果您遇到与我相同的问题，了解其他方法或有什么需要指出的地方，我将非常有兴趣收到您的来信！

Answer 1

首先，正如其他评论者所说的那样，您必须查看 DDD 的目标并决定该方法是否有价值。 DDD 增加了架构的一些复杂性（大部分是在构建项目和基本类型的初始阶段）以及之后您必须处理的样板和仪式的数量。

在许多情况下，更简单的设计，例如CRUD 方法，效果最好。 DDD 的亮点在于应用程序本身在功能方面更加复杂和/或功能的数量预计会随着时间的推移而显着增长。技术优势可以体现在模块化、可扩展性和可测试性方面，但 - 最重要的是恕我直言 - 提供了一个流程，您可以在其中带领非技术利益相关者并将他们的愿望转化为代码，而不会在此过程中失去他们。

有一系列很棒的博客文章 Wild Workouts Go DDD Example，可通过几个步骤带您完成从传统的基于 Go CRUD 的 REST API 设计到成熟的 DDD 架构的重构过程。

Robert Laszczak，该系列的作者对 DDD 的定义如下：

<块引用>

确保您以最佳方式解决有效问题。之后以您的企业能够理解的方式实施解决方案，无需任何额外的技术语言翻译。

他认为 Golang + DDD 是编写业务应用程序的绝佳方式。

理解这里的关键是决定你想在你的设计中走多远（没有双关语）。重构逐渐引入了新的架构概念，在每个步骤中，您应该决定它是否足以满足您的用例，权衡利弊以进一步发展。他们从 DDD Lite 版本开始非常 KISS，然后在 CQRS、Clean Architecture、微服务甚至事件溯源方面进一步发展。

我在许多项目中看到的是，他们立即进入了 Full Monty，造成了矫枉过正。尤其是微服务和事件溯源会增加很多（偶然的）复杂性。

我还不是很精通 Go（实际上对这门语言还很陌生），但会尝试您的选择并提供一些注意事项。也许更多有经验的 Go 开发人员可以纠正我，我去的地方 :)

对于我自己的项目，我正在研究清洁架构 (Ports & Adapters, Inversion of Control) + CQRS + DDD 组合。

Wild Workouts 示例提供了充足的灵感，但需要在这里和那里进行一些调整和添加。

我的目标是，在代码库的文件夹结构中，开发人员应立即识别功能/用例（史诗、用户故事、场景）所在的位置，并拥有直接反映 Ubiquitous Language 和可单独测试。部分测试将是客户和最终用户可以轻松理解的纯文本 BDD 脚本。

将涉及一些样板文件，但是 - 鉴于上述情况 - 我认为利大于弊（如果您的应用程序需要 DDD）。

你的选项 1 对我来说看起来最好，但有一些额外的观察（注意：我会坚持你的命名，这会让其中一些看起来有点矫枉过正......同样，这是想法数）。

我会说 Entity 代表一个 Realm，而不是 AggregateRoot。
这可以是隐式的，也可以内联 base.AggregateRoot。
聚合根是域的访问点，并确保其状态始终一致。
因此 Realm 的内部状态应该是不可变的。状态更改通过函数发生。
除非真的很琐碎并且不太可能改变，否则我会在单独的文件中实现 FriendlyName 值对象。
域的一部分还有 RealmRepository，但这只是提供了一个接口。

现在我使用的是 CQRS，它是对您的代码片段中显示内容的扩展。在此：

应用层中可能有一个 ChangeFriendlyName 命令处理程序。
处理程序可以访问存储库实现，例如InMemRealmRepository。
可能会将 CreateRealmParams 传递给命令，然后命令进行验证。
处理程序逻辑可能首先从数据库中获取 Realm 聚合。
然后构造一个新的FriendlyName（也可以封装在一个Realm函数调用中）。
对 Realm 的函数调用更新状态并将 FriendlyNameChanged 事件排队。
命令处理程序将更改保存在 InMemory 数据库中。
仅当没有错误时，命令处理程序才会对聚合调用 Commit()。
现在通过 EventBus 等方式发布一个或多个排队事件，并在需要时进行处理。

至于选项 #1 的代码有一些变化（希望我做对了）..

realm.go - 聚合根

type Realm struct {
   base.AggregateRoot

   friendlyName FriendlyName
}

// Change state via function calls. Not shown: event impl, error handling.
// Even with CQRS having Events is entirely optional. You might implement
// it solely to e.g. maintain an audit log.
func (r *Realm) ChangeFriendlyName(name FriendlyName) {
   r.friendlyName = name
   
   var ev = NewFriendlyNameChanged(r.id, name)

   // Queue the event.
   r.Apply(ev)
}

// You might use Params types and encapsulate value object creation,
// but I'll pass value objects directly created in a command handler.
func CreateRealm(id base.AID, name FriendlyName) (*Realm, error) {
   ar := base.NewAggregateRoot(id)

   // Might do some param validation here.

   return &Realm{
       AggregateRoot: ar,
       friendlyName: name,
   }, nil
}

friendlyname.go - 值对象

type FriendlyName struct {
    value string
}

// Domain error. Part of ubiquitous language.
var FriendlyNameInvalid = errors.New("invalid friendly name")

func (n FriendlyName) String() string { return n.value }

func NewFriendlyName(input string) (FriendlyName, error) {
    if input == "" {
        return FriendlyNameInvalid
    }
    // perhaps some regexp rule here...

    return FriendlyName{value: input}, nil
}

Golang和DDD域建模

1 个答案: