集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ

本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ

[little_hands]

パターン3の拡張で、ユーザー数の制約を管理する別の集約を作る案 https://twitter.com/little_hand_s/status/1069371669230145537

[tinsep19]

ユーザーは無効で追加し、有効化を組織の役割に、で良くない？ユーザー数ライセンスだが、個人ライセンスの付替行為が暗黙的に発生しているとし、アクティベート要求をキューで順次処理かな

[programmablekinoko]

こういう設計の詳細を書いたdocは貴重

[yojik]

シンプルにユーザと組織の間に「所属」集約を作るかなぁ （個人的には集約をトランザクション境界にするDDDのアイディアは全く納得してないけど、どちらにしろこのケースなら所属オブジェクトは必ず必要)

[teracy_junk]

そういや、DDDの記事でユビキタス言語を最初に定義しているの珍しいかもしれん。DDDの記事なのに

[katzchang]

契約ルールの方を柔軟にするかなぁ。固定金額契約でも、多少のオーバーは運用上許容してるサービスは多い印象がある。リアルタイムにbanする必要はないので、定期チェック機構を組織のほうに作るとよさそう。

[nunulk]

解決策2、無効化した状態でユーザー登録しておいて、制限範囲内であることが確認されたら有効化する、という逆の流れではダメだろうか。結果整合性を一定時間でチェックするデーモンとともに

[rryu]

モデルというよりクリティカルセクションをどうするかという感じだが、楽観的ロックを使うならロック用のモデルを作るのが良さそう。

[azihsoyn]

createユーザーとjoin組織を分けるとかかなぁ

[fukuchiharuki]

集約と整合性についてのお悩み：ユーザーの「状態」で表現したいことが大きすぎるのかもしれない

[masa8aurum]

「組織>ユーザー>記事」というモデルでユーザー追加時に有効ユーザー数上限という制約（ビジネスルール）がある場合の例。 // 続編→https://kbigwheel.hateblo.jp/entry/2018/12/03/aggregate-and-consistency-answers

[kat21]

後日のまとめに期待！

[efcl]

ショッピングカートの在庫管理でよくみる問題。 フロントで考えると、ReduxでのSingle Storeのやり方は1、FB FluxのwaitForのやり方は3かな。 DDD関係なくステート管理するなら同じ事を考える必要がある感じ

[tsimo]

“利用”

[bufferings]

面白そう。あとでよむー。

[snowcrush]

DDDはコンセプト自体はいいのだけれどよくある設計パターンはRDBMSと併用すると途端に破綻するのでちょっと信用がおけない。// あ、誤読していた。しかし結局制約を外部に持たせられないという意味では同じか

[Windymelt]

DDD

[turanukimaru]

組織はユーザの集約である必要はなく、名簿の集約であれば良い。ユーザが組織に使用権を問い合わせる。名簿にIDと有効無効と登録順になるなにかを持たせれば超過しても組織で判断できる。あとでちゃんと書く。

[benridane111]

論理削除とユニーク制約の組み合わせだと思って危険信号でた。論理削除やめたらと思う。

[j5ik2o]

おー、すごい面白い記事！このあとゆっくり読む！