アーキテクチャ on yyh-gl's Tech Blog

【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章コミュニケーションと言語の使い方

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

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

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

共通言語としてのモデル

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

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