DDD on yyh-gl's Tech Blog

texta.fm #1 まとめ

Thu, 01 Oct 2020 09:00:00 +0900

texta.fm

texta.fm #1（2020年8月27日放送分）を聞いて、特にDDDについて学びが多かったのでまとめました。

エヴァンス本を読む前に知っておいた方がいい時代背景、そして、意識すべき点を知ることができるので、
時間があればぜひ実際に聞きに行ってみてください。

話者：

@_yasaichi さん
@t_wada さん

以降、勉強になった点を抜き出していきます。
なお、<>内に記載している時間は、記述内容が実際に話されている時間を示しています。

DDDが解決したかった問題

<6分30秒ぐらいから>

エリック・エヴァンスがDDDで解決しようとしていた問題は以下の2点

分析モデルとコード間の乖離：詳細は後述
ビジネス側と開発側の乖離：ビジネス側の言葉と開発側の言葉が異なることによる開発の複雑化

分析モデルとコード間の乖離ってなに？

<9分45秒ぐらいから>

2000年代前半はフェーズで区切ったソフトウェア開発が主流だった。
そして、その区切られたフェーズのひとつである「モデリングフェーズ」では、
分析や設計を通してモデルを作り上げていくのであるが、
開発の対象領域をきちんと写し取った抽象的なモデル（分析モデル）を作ることが最大の目的であった。

しかし、開発フェーズに入った時、分析モデルでは不完全なことが多かった。
よって、開発で使えるように修正が加えられ、最終的には分析モデルとは全く異なるモデルができあがる。

コードを書かないと分からないこと、実際にシステムが使われ始めないと分からないことがたくさんあるので、当然の結果である。

解決策：改善のループを回そう

<17分20秒ぐらいから>

分析モデルとコード間の乖離を解決するために、
分析モデル→開発時のモデルの一方通行ではなく、
開発時のモデル↔分析モデルのように両方向にフィードバックする。
そして、フィードバックをもとに改善のループを回していくことが重要。
（＝アジャイルソフトウェア開発時代の改善ループの回し方）

今はあまり分析モデルとコード間の乖離が問題にならない

<25分00秒ぐらいから>

現在ではあまり分析モデルとコード間の乖離が問題にならない。
理由としては、分析モデルの作成フェーズ（モデリングフェーズ）と開発フェーズを担当する人が同じになってきたから。

昨今の開発ではこうした開発体制が普通になっているので、
そもそも今いる大半のエンジニアにはイメージがつきにくい事象である。

したがって、現在は、DDDと言われるとビジネス側と開発側の乖離に注目が行きがち。

エヴァンス本から学ぶべき大事なこと

<21分40秒ぐらいから>

コードとドメイン知識間の乖離を無くし、
一致させ続ける反復的作業こそが大事であると訴えたことがとても良かった。

つまり、先述したとおり、
フィードバックが 分析モデル→開発時のモデルの一方通行 だったものを
開発時のモデル↔分析モデルのような両方向 にしようと提唱したことこそが最重要。

ここを意識して学ぼう！

<33分00秒ぐらいから>

デザインパターンの部分（2部、3部あたり）はもちろん大事であるが、
エヴァンス本の本質的な部分ではない。

【Go+DDD】エンティティと値オブジェクトの実装方法（自己流）

Fri, 08 May 2020 09:00:00 +0900

GoでDDD

今担当しているプロジェクトでは、GoでAPIを作っています。
このプロジェクトでは、DDDの考え方や設計パターンも取り入れています。

今回はDDDの設計パターンの中でもEntityとValue Object（VO）について、
僕がGoでどうやって実装しているのか紹介していきます。

実装例

兎にも角にも、まずはコードを示します。

// animal/dog/dog.go
package dog
type Dog struct {
name Name
}
func New(name string) (*Dog, error) {
n, err := newName(name)
if err != nil {
return nil, err
}
return &Dog{
name: *n,
}, nil
}

// animal/dog/name.go
package dog
import (
"errors"
"unicode/utf8"
)
type Name string
func newName(v string) (*Name, error) {
// 名前は3文字以上というビジネスロジック
if utf8.RuneCountInString(v) < 3 {
return nil, errors.New("名前は3文字以上！")
}
n := Name(v)
return &n, nil
}

// main.go
package main
import (
"fmt"
"playground/animal/dog"
)
func main() {
// d := dog.Dog{name: "犬太郎"} できない
d, _ := dog.New("犬太郎") // できる
fmt.Printf("%+v\n", d)
d, err := dog.New("犬")
if err != nil {
fmt.Println(err) // 犬の名前が「犬」は可愛そうだからできない()
}
}

playground

【DDD】集約とトランザクション境界について調べたことメモ

Tue, 18 Feb 2020 09:00:00 +0900

簡単まとめシリーズ

今回は 集約とトランザクション境界 について、
自分のわからないところを調べたので、メモとして残しておきます。

集約

集約の説明を『ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本』から拝借すると、
「データを変更するための単位として扱われるオブジェクトの集まりを集約といいます」とのこと。

↓ もうすこし具体的に言うと

DDDではエンティティと値オブジェクトというものがありますが、
値オブジェクトを直接触らず、エンティティ経由でしか変更しないようにするというものですね。

このような制限をかけることで、
ひとまとまりにされたオブジェクト間で維持されるべき不変条件を守ることができます。

トランザクション境界

基本的な考えとしては、集約ごとにトランザクションを貼ります。

↑この基本を守るためにも、理想としては正しいモデリングにより、
正しいトランザクション境界を見つけることが大事です。

正しいトランザクション境界を見つけることは、不用意に大きなDBロックの発生を防止します。

しかしながら、集約をまたいでトランザクション制御したくなるときもあります。
→ 参考例

こういうときにどうするか、上記リンクでもいくつかの方法が挙げられています。
他のサイトも調べてみましたが、だいたい同じような方法が出てきました。

結果整合性

主流っぽい
- いろいろなサイト、書籍の中で紹介されていました
整合性を担保するための仕組みづくりが必要
- 整合性をチェックするためのバッチなど

集約をまたいでトランザクションを貼る

下記理由のためにあまり推奨されない
- ロック範囲が大きくなってしまう
- 守るべき「データの一貫性の境界」をコード上で表現できなくなる
  - 参考サイト

複数の集約をさらにまとめた集約をつくる

ロック範囲が大きくなってしまうため、あまり推奨されない

結果整合性

結果整合性については、
『ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本』の
12章3説「集約の大きさと操作の単位」で言及されているので、もう少しだけ詳しく調べました。

結果整合性とは、最終的に整合性の取れていればOKという考え方。
したがって、整合性が取れていない状況が起こり得るが、それは許容する。

「最終的に整合性を取る」ってどうやるの？
→ こちらが参考になる。

まとめ

設計周りの話は、唯一無二の答えがあるわけではありません。

よって、今回の話においても「データの一貫性の境界」を意識し、
ちゃんとメリットとデメリットを理解した上で最善の解を選択する必要がありますね。

参考資料

【Go + レイヤードアーキテクチャ】DDDを意識してWeb APIを実装してみる

Fri, 14 Jun 2019 09:00:00 +0900

更新（2019年10月30日）

初回投稿から3ヶ月経ちました。
この3ヶ月で新しく得た知見を基に、内容を一部アップデートしました。

今回やること

Goのディレクトリ構成についていろいろと調べる中で、
こちらの資料がとても分かりやすかったので、
今回はこちらを参考にGoでWeb APIを作っていきたいと思います。

加えて、本プロジェクトでは、DDD とレイヤードアーキテクチャを取り入れます。
（内容はほぼレイヤードアーキテクチャになってしまいましたが…）

DDD については、「DDD を Go とレイヤードアーキテクチャでやるなら、こんな感じかな？」という個人の見解レベルです。
パッケージ構成の参考になれば幸いです。
（なので、ドメインモデルは重度の貧血症）

環境

MacOS Mojave 10.14.6
Go 1.12.5

なお、今回は、Gin や Mux などといったフレームワークは使わず、
httprouter のみで薄く作っていこうと思います。

Mux を使った実装は僕の前のブログで紹介しているのでよければどうぞ。

・

では、早速本題に入っていきましょう。

採用アーキテクチャ：レイヤードアーキテクチャ

参考記事内で紹介されているのはレイヤードアーキテクチャをベースに
いろいろカスタマイズされたものらしいです。

クリーンアーキテクチャに似たアーキテクチャだとか。

ユースケース層という呼び方はクリーンアーキテクチャ由来ですね。

DDD の文脈ではアプリケーション層と呼ばれますが、
アプリケーションって意味が広くて分かりづらいので、
本プロジェクトではユースケースという単語を使用します。

とりあえず、今回はスライドページ19で紹介されているディレクトリ構成に従って、
DDD を意識して Web API を実装していこうと思います。

（意識だけして、実践できずに終わりましたが😇）

レイヤードアーキテクチャにおける各層の依存関係について説明します。

依存関係の図は下記のとおりです。

矢印は依存の方向を示しています。
例えば、上図だと Handler層は UseCase層の処理を利用することを意味します。

【エリック・エヴァンスのドメイン駆動設計】DDD入門 Part 1

Tue, 11 Jun 2019 09:00:00 +0900

DDD の勉強始めます

新卒研修を受ける中で DDD が出てきて、勉強したくなったので、
『エリック・エヴァンスのドメイン駆動設計』（エリック・エヴァンス著，今関剛監訳，和智右桂、牧野祐子訳）を読んでいこうと思います。

今回は第1部「ドメインモデルを機能させる」の 1章と 2章をまとめます。

注意：僕の理解をそのままメモとして書き連ねていきます。
したがって、誤った理解もあると思うので、そのときはDMとかでご指摘お願いします！

1章知識をかみ砕く

ソフトウェアを作るときに、はじめから対象を十分に理解している開発者などいない。

対象＝これから作るソフトウェアで実現する作業＝ドメイン

したがって、対象について詳しい人（ドメインエキスパート）と開発者で
十分に話し合って理解を深めることが重要である。

理解したことはモデルとして書き出す。
そして、ドメインエキスパートは足りないところがあれば追加で説明する。
開発者は分からないところがあれば質問する。

上記工程を何度も繰り返し、その都度得た知識をモデルに落とし込んでいく。
→ 継続的学習（継続的学習は開発が始まった後でも行う）

はじめから対象を如実に表したモデルを作れることは滅多にない。

ドメインエキスパートと開発者では見ている視点が違うので少し話を聞いたぐらいで
完璧なモデルを作ることができないのは当たり前である。

だからこそ、対話を通して、互いに疑問点や不要な点を洗い出し、洗練する必要がある。
これが知識のかみ砕きである。

1章まとめ

ドメインエキスパートと開発者が話し合ってドメインをモデルに落とし込んでいく
- 用語の説明や不足点の追加などとにかく話す
- ドメイン：ソフトウェア化する対象（業務やサービスなど、ソフトウェア化の対象となりうる万物）
一発で完璧なモデリングはできないから、継続的に改善していく

2章コミュニケーションと言語の使い方

ドメインエキスパートが使う専門用語を開発者は理解できないし、
開発者が使う専門用語をドメインエキスパートは理解できない。

ドメインエキスパートと開発者の両者が同じ意味だと思って使っていたとしても
たいていの場合、差異がある。

このような差異があると通訳が必要となる。
通訳はコミュニケーションを鈍らせ、知識のかみ砕きを沈滞させる。

共通言語としてのモデル

通訳をなくすために、モデルを言語の骨格として使用する。

ドメインエキスパートと開発者のコミュニケーションやコード、ドキュメント、図など
全てにおいて、その言語を使用する。