「集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話」に頂いたアイデアまとめ

[集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 \- kbigwheelのプログラミング・ソフトウェア技術系ブログ https://kbigwheel.hateblo.jp/entry/2018/12/03/aggregate-and-consistency に対してtwitter上で頂いたアイデアをまとめました。後日これを更にブログ記事へまとめる予定です。 可能な限り拾ったつもりですが、もし漏れているつぶやきありましたらすみません。
DDD
552view 0コメント
このまとめをお気に入りにして応援しよう!
0
🤓k.bigwheel🤓 @k_bigwheel
DDDアドベントカレンダーの記事公開しました。もし解決策のアイデア等ありましたらこのtweetに返信してもらえるとうれしいです。 集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプロ… kbigwheel.hateblo.jp/entry/2018/12/…

DM, RTなどで反応できたもの

松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel 結果整合性がどうしてもコストが大きくて、同一トランザクションでやりたい場合、という前提で考えてみました。 5. パターン3の拡張で、ユーザー数の制約を管理する別の集約を作る 企業の中に他集約の数に応じたカウントを持つのはやはり違和感があるので、その部分だけ切り出してしまう。(続)
松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel 名前はいいのが思いつかないので仮で「ユーザー登録数」みたいなのにして、それで1集約 パターン3で企業集約でやっている処理をこっちに差し替える。ユーザー数の管理という責務が企業から剥がされるので凝集度が少し上がる。
松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel 普段これでやってる、とかではなくて完全に記事読んでの思いつきです笑 なのでうまくいくかはわかりませんが1アイデアとして…! 問題と選択肢が整理されていてすごく参考になりました、ありがとうございました!!
🤓k.bigwheel🤓 @k_bigwheel
@little_hand_s いえいえ、あの長文を読んだ上で解決のアイデアまで書いていただきありがとうございました! ユーザー登録数 集約を作ればトランザクション境界内の要素も減ってデッドロックやロック開放待ちが減るのもいい感じですね。ありがとうございます!!
松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel いえいえ、こういう話好きなのでw ここまで具体的な事例が出ること少ないので貴重でした!
松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel 追記します 今回は集約間の整合性を取る難しさよりも、1集約内での件数に関するトランザクション周りの難しさの方が大きいように思いました。 例えば1集約内でもデータ重複を避けるなどの要件があれば同じ問題が生じそうです。
松岡@DDDブログ書いてます @little_hand_s
@k_bigwheel そのため、そこの整合性担保を他の集約に求めるとそちら側の責務過剰で凝集度が下がってしまうので、複数集約トランザクションという手を取るとしても自分の集約の延長でなんとか、という方針で考えました。
増田 亨. @masuda220
@k_bigwheel 私なら組織オブジェクトが、現在の有効ユーザ数を持つようにするかな。 ユーザ追加できるか問合わせるメソッドを用意する。 組織オブジェクトは常にメモリ上に存在して、適切に状態が更新されると「仮定」する。 リポジトリをDBアクセスのラッパーではなく、メモリ上のオブジェクト操作と考える。
増田 亨. @masuda220
@k_bigwheel 上限数ルールに関係する値以外を徹底的に削ぎ落として、とってもシンプルなモデルを考えてみると、こういう設計の選択肢が見つかると思います。 ロジックの置き場所を考える時は、データベースへの記録と参照は、一旦は忘れてみるのが、良い設計を見つけることにつながることが多いと思います。
🤓k.bigwheel🤓 @k_bigwheel
@masuda220 アイデアありがとうございます😁 確かによりリポジトリをDDDの原義らしく捉えるとそうなりますね。 ちなみに複数コンテナで動かす場合、組織オブジェクトの更新はどうやって最新に保つイメージですか?
🤓k.bigwheel🤓 @k_bigwheel
@masuda220 僕の知識では複数コンテナ(複数インスタンス)にするとどうやってもコンテナ感で有効ユーザー数の更新に遅延が発生してしまうため、 `ユーザー追加`メソッドをそれぞれのコンテナで同時に呼ばれてしまうと上限を超えてしまうことを防げないように思えました。
増田 亨. @masuda220
@k_bigwheel どの程度の厳密な制限が必要か、制限違反の時の問題の深刻さ、制限違反が起きそうな確率、などに依存しますね。 一時的な制限違反が許容できるなら、登録時(before and/or after)に各自が最新チェックでよしとする。 厳密さが必要なら、シングルトンの登録許可サービスを作ってロックするとか。
増田 亨. @masuda220
@k_bigwheel 完全に防ぐのは難しいですね。 大規模に並列で運用しているところは、厳密な制限の作り込みよりも、ある程度の不整合を許容する前提で設計と運用する方向を模索しているように思います。 事後チェックとか。
🤓k.bigwheel🤓 @k_bigwheel
@masuda220 ありがとうございます、いわゆる結果整合性ですね。 そこを許容するようにドメインエキスパートやシステム利用者と交渉して、仮に上限を超えたとしてもメールやslackアラートで知らせるようにする、というのもありですね 👍
TANIGUCHI Kousuke @tinsep19
@little_hand_s @k_bigwheel ユーザー追加を無効状態で追加して、アクティベーションする役割を組織の役割として持つのでよいのではないでしょうか? 早すぎる抽象化だとは思いますが、精緻に行うなら有効ユーザー上限は具象であって、そこにあるべきは有効化ポリシーだと思います。
🤓k.bigwheel🤓 @k_bigwheel
@tinsep19 @little_hand_s ありがとうございます! twitter.com/nrslib/status/… こちらでも同様のアイデアが出ていまして、おそらくおっしゃる方法が一つの模範解答ではないかと思いました。 後日頂いたアイデアをまたブログにまとめようと思います!
nrs @nrslib
自分がやるときは組織に現在の有効ユーザの id 配列を持たせそう あとは有効化させてから無効にするのではなく、ユーザ追加とユーザの有効化の二つの処理に分割して、ユーザ追加は成功するけどユーザの有効化は失敗する可能性がある、という結果整合性に寄せていきそう twitter.com/k_bigwheel/sta…
🤓k.bigwheel🤓 @k_bigwheel
@nrslib アイデアありがとうございます! twitter.com/tinsep19/statu… こちらでも無効化して追加したのち有効化するというアイデアが挙げられていて、結果整合性を採用するパターンではそれが一つの模範解答ではないかと考えています。
nrs @nrslib
@k_bigwheel おぉ、これはご丁寧にありがとうございます 適当に呟いたやつでしたので申し訳ない気持ちに! アイデアがブログにまとまるのを楽しみにお待ちしておりますー

反応できていないもの

こむ @petitviolet
一般論なら結果整合で、今回の具体例ならユーザーを無効にしておいてユーザー数制限にカウントしない or 同時追加なんてそんな無いはずと信じて31人になるくらいは雑に許容してしまう、かな。 kbigwheel.hateblo.jp/entry/2018/12/…
Ktz @ktz_alias
貧血症を怖がるあまり、複数のエンティティにまたがる振る舞いを1つのエンティティに押し込んだために起きる悲劇の一例じゃね?知らんけど。 kbigwheel.hateblo.jp/entry/2018/12/…
とーます@悪いオタクらしい @grimrose
トランザクションの話はおくださんのblogを参照するとして、どこまで厳密に守らないといけないかだろうなぁ… / 集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ kbigwheel.hateblo.jp/entry/2018/12/…
残りを読む(10)
ログインして広告を非表示にする
ログインして広告を非表示にする