- ドメインとは、広い意味で言うと「組織が行う事業やそれを取り巻く世界」のことである(P.41)
- IDDD本では、コアドメインやサブドメインといった用語を使うときは、この広いドメインの一部分の領域を指す。(P.42)
- ほとんどのソフトウェアのドメインは、複数のサブドメインを持ち、それらを組み合わせて、組織すべてのドメインを作り上げることになる
- サブドメインには、コアドメイン、支援サブドメイン、汎用サブドメインにカテゴライズされる
- サブドメインの例を、小売業者による商品のオンライン販売で考える。(P.42-43)
- 現在稼働中のシステムは DDD 以外の方法で作られているものが多く、一つのシステムがたくさんの業務機能(=サブドメイン) を持ちすぎている可能性がある。
- サンプル(図2-1) の「Eコマースシステムドメイン」には、3つの物理システムが含まれている。
- その1つである「Eコマースシステム」にも『商品カタログ・注文・請求・発送』という、4つものサブドメインがあり、システムが複雑・肥大化している。(P.43)
- こうした状況では何か新たな機能を追加しようとしても、各サブドメインの関心ごとが衝突しやすくモデルの変更の障害となる。(P.43)
- このように、本来サブドメインとして分割されているべきドメインモデルをうまく分割できていないと、モデルがお互いにつながっていたり依存しあったりしてしまうため、変更が困難になる。(P/44)
- このような複雑さには、 DDD を使って実際の機能に基づいたサブドメインに切り分けることで対処可能である。※その切り分けた結果が図2-1の破線である。 (P.44)
- サブドメインの例を、小売業者による商品のオンライン販売で考える。(P.42-43)
- 商品オンラインの販売例の図2-1（多分ドメイン駆動設計を用いた最終型の図）では、Eコマースシステム、在庫システム、需要予測システムがある。(P.42-)
- Eコマースシステム内では、商品カタログ、注文、請求、発送を抱えている。新機能を追加時に、お互いの関心事が衝突すると変更が困難となるので、実際の機能に基づいたサブドメインに切り分ける(P43-44)
- 小売が抱えている問題は、在庫コストがかさむことである。そこで、たとえば需要予測システムと、発注サブドメイン、境界づけられたコンテキストである在庫を統合（結合？）し、新たなソリューションを作ることができる。(P.45)
- DDDを実践する際は、個々の境界付けられたコンテキスト内の用語の意味を確実に理解しようと心がけること。Eコマースシステムは4つの暗黙的なサブドメインを含んでいるが、たとえば「顧客」という用語は商品カタログサブドメインと注文サブドメインでは意味合いが異なったりする。(P.45-46)
- 企業システムにおいて、単独で存在する境界付けられたコンテキストはほとんど存在しない。そのため、複数のシステムやモデルを統合(=共同作業) する必要がある。(P.47)
- 用語をモデリングして、概念をきちんと抑えて、明確に用語をモデリングすることで、境界付けられたコンテキストを分割することができる。(P.46-47)
- コアドメインに注目する
- コアドメインは、業務ドメインの一部。サブドメインの中で事業を成功させるために不可欠なもの
- 支援サブドメインは業務を遂行するのに不可欠だがコアドメインではない
- 汎用サブドメインはソリューション全体として必要とするドメイン
- p.41 「ドメインとは、広い意味でいうと、組織が行う事業やそれを取り巻く世界のことだ」
- 「広い意味」と言いつつ、狭い気がする
- domain = ある知識/関心/活動の領域
- ここで「組織が行う事業」と言う時点で、「組織」「組織が行う事業」という領域に限定されている
- 少なくとも、個人的な関心/知識/活動は排除されているように見える
- ここでの「ドメイン」の時点で、既にDDDの文脈 = 何かしらのビジネスを対象とする、という前提を持っているように感じる
- DDDの文脈で言えば、十分に広い意味と言って良いのかも？
- 「広い意味」と言いつつ、狭い気がする
- ✅ 図2-1で、Eコマースと在庫システム、需要予測システムが境界づけられたコンテキストとして表されているが、サブシステム＝境界づけられたコンテキストとして考えてよい？👍👍
- // （議事メモの頭に//つけます）
- // 1:1で対応付けられるのが望ましいが、必ずしもそうではないと述べられている。あくまで1:1になるのが理想
- // 理想を示したものではなく、あくまでDDDで作られていないシステムのサンプルでは？
- // 境界付けられたコンテキスト(bounded context) は文字通り境界付けられているものなので、明確に境界を引けるかどうかになると思います。
- // 例えば、開発チームが分かれても大丈夫。
- // 開発の物理拠点が分かれても大丈夫。
- // （必ずしも分かれる必要はないけど）
- // みたいな。
- // サブシステム単位で隔離できるのが理想というのはそのとおりな気がします。
- P.45で出てくる「論理的サブドメイン」というのは、「サブドメイン」と明確な違いがあるのか？
- ✅ そのドメインがコアドメインであるかどうか、誰がいつどうやって決めるのが多いんでしょう？最初はコンテキストの境界が適切なドメインの単位がわかっていないと思いますが、どこかのタイミングで「これがコアドメインだ」とわかってくるタイミングがあると思います。その時、ドメインエキスパートなり、ビジネス側で権限を持つ人が決める？👍
- // 実体験など
- // 決める、というよりは、関係者同士で合意を取るというものでは
- // 決定権を委ねるような形は望ましくないのでは
- // 「やりたい方向ってこれですかね？」「あってますか？」というようなコミュニケーションを取っていく
- // コアドメインって本当に主要なものだから、あまり意見はわかれずボンヤリ共通認識があるものだと思ってた
- // あくまでビジネスのコアかどうかはドメインエキスパートでないとわからないという事では？
- // これがコアドメインであると仮定をして進めていくというアプローチになるのでは
- // 競争力の源となるものがコアドメインなので、ドメインエキスパートとのコミュニケーションによってなされる
- // 作っているシステムが価値を出す領域はなにか？という問いへの回答が、コアドメインだと認識してます。
- // コアドメインはビジネスの中心になるものだからビジネスの目的がハッキリしていれば自ずと見えてくるのかなと理解していました
- // コアドメインはそのドメインを存在させるアイデンティティに繋がる部分ですので、基本的にはだいたい見えているはず。時にそうでないときもある、くらいかと。
- // 実体験など
- p.44 「機能に基づいたサブドメイン」
- 機能単位でサブドメインを分割せよ、と言っているように一読して思ったが、後々の記述も含めると「業務に基づいたサブドメイン」という表現の方が適切そうに感じた。この解釈は妥当か？
- p.45 「新たなコアドメイン」
- 「新たな」ということは、過去に少なくとも１つコアドメインが見つかっていそうに思うけれど、ここまで「これはコアドメイン」という記述が有った？（Eコマースのことだろうか）
- コアドメインってそんなにたくさん生えてくるもの？
- コアドメイン = ビジネスにおける競争力の源？
- であれば、むしろたくさん有る方がビジネス的には良いのか
- コアドメインを発掘するには、視点を大きく転換する必要があるかもしれない
- p.45 「その手のサブドメインはモジュールとしてコアから分離すればいい」
- サブドメイン/モジュール/コアの関係は？
- 9章読めばピンとくるのだろうか
- p.47 「単独で存在する境界づけられたコンテキストなどめったにない」
- サブドメインの単位と境界づけられたコンテキストの単位は一致しない、ということ？
- 後の文章だと、一致させるのが望ましいらしいけれど。
- 一致しないのは良いとして、境界づけられたコンテキストは何を基準に定義されるのか
- 3章でやるらしい
- サブドメインの単位と境界づけられたコンテキストの単位は一致しない、ということ？
- ✅ p.48 支援サブドメイン/汎用サブドメイン
- 「まだコアドメインとは言えないようなモデル」 = 支援サブドメイン
- 支援サブドメインが、今後コアドメインに変化することも有るということ？ 👍
- // こういうパターンはありそう
- // 最初はコアを支援する役割だったものが、サービスの成長に合わせて重要な役割を持つ形としてコアドメイン化するということはあるのでは
- // 支援サブドメイン → コアドメイン になるってのは、もはやビジネスが変わっているって感じがしますね。
- // 経年でビジネス環境が変わることはあるので、それまでコアでなかったドメインがコアドメインになるということはある
- // ドメイン = 広い意味では「組織が行う事業」のことなので、時代や技術の変化で、それまでコアで無かった領域/事業が一つの主要な事業となるケースはありそう
- // サブドメインがコアドメインに変わることはありえます。スタートアップがピボットするときというのがそれにあたります。
- 汎用サブドメイン = Util的な臭いを感じるけれど、実際のところどうなんだろう
- 止むに止まれず仕方無しに定義する、というイメージを持ったけれど、実践的には？
- // 近しい認識で良いと思います。
- 止むに止まれず仕方無しに定義する、というイメージを持ったけれど、実践的には？
- と思ったら、「支援サブドメインであるか汎用サブドメインであるかは、それほど重要ではない」うーん
- DDD 初心者がハマりがちな罠に、『コアとなる複数の概念を、ひとつの汎用的な概念に混ぜ込んでしまい、ひとつの概念の中に２つのモデルを作ってしまう』というものがある。(P.50, 図2-3)
- 例で言うと、投稿者、モデレータはコラボレーションとしての用語としても概念としても適切たが、ユーザやパーミッションは果たしてコラボレーションツールの概念として適切だろうか？(P.51)
- ユーザとパーミッションについて議論し、論理的なセキュリティサブドメインとして切り離すことにより、別のところのコアドメインでも使えると認識した(P.52)
- クリーンなモデリングをすすめることにより、巨大な泥団子となることを回避できる。(P.52)
- P.50の失敗パターンは、P.67の「技術的コンポーネントがコンテキストを定めるものではない」に通じる？ 技術的コンポーネントが、言語的な境界（≒境界づけられたコンテキスト）を定められない？
- ドメインは、問題空間と解決空間を持っている（P.53）
- 問題空間＝解決すべきビジネス戦略上の課題を浮き彫りにするもの。
- 問題空間はドメインの一部であり、新しくコアドメインを生み出すために開発を要するものである。
- 従って、そのコアドメインに必要なサブドメインも、問題空間に含まれる。
- 解決空間＝ソフトウェアをどのように実装してその課題に着目するもの。
- 境界づけられたコンテキストのこと。
- 境界づけられたコンテキストは特定のソリューションを表すものであり、それを具現化したビュー(システムやソフトウェアなど)である（P.54）
- 問題空間＝解決すべきビジネス戦略上の課題を浮き彫りにするもの。
- 何らかのソリューションに取り組む前に、問題空間と解決空間を「評価」する必要がある。コアドメインのビジョンやゴールを理解せず、それを支援するドメインの範囲を把握しないままではうまくいかない。(P.54-55)
- 評価の例
- 戦略的コアドメインの名前とそのビジョンは？
- 戦略的コアドメインの一部として検討すべき概念は？
- どんな支援サブドメインと汎用サブドメインが必要になる？
- そのドメインの各部分を担当するのは誰？
- チームに適切なメンバーを集めることができる？
- 評価の例
- 問題空間とは、そのドメインにおける解決すべき課題？ たとえば、P.42のオンライン販売の例だと、「買い物客に見せる商品カタログが必要」「買い物客からの注文を受け付けられないといけない」「販売代金の徴収する必要がある」「買い手に商品を発送できないといけない」が、問題空間？:+1:
- P.54 の「アセスメントビュー」とは何だろう？評価用のビュー…？評価用のシステム？フレームワーク？:+1::+1::+1:
- // ググっても出てこない
- // 抽象的な業務ドメインのテンプレートと質問リストを使ったレビューだったかと
- // 答えでなさそうなのでスキップ
- // それっぽい記事あった ←原著の図2.7
- // 同様の図2.4が出てくるところの説明:
- // ｐ.54 「何かのソリューションに取り組む前に、まずは問題空間と解決空間を評価する必要がある。以下に、いくつか質問を用意した。これらにきちんと答えられなければ、プロジェクトを正しい方向に導けない。」
- // このような、問題空間 (と場合によっては解空間の対応) が適切かを評価する観点 (とその表現) のことと読める
- // 「アセスメントビュー」よりも (上記のような) 「評価観点」と訳されていたら戸惑いは少なかったかも
- // 同様の図2.4が出てくるところの説明:
- ✅ p.54 問題空間/解決空間 👍 👍
- 問題空間 = 「何をすべきか」「何を必要としているか」「何を作ろうとしているか」
- 解決空間 = 「どのように達成するか」「達成に必要な道具は何か」
- という感じ？
- // 解決空間＝境界づけられたコンテキスト、という記述はあり
- // 「問題空間 = 現実世界、解決空間 = コンテキスト、モデル、ソフトウェアの世界」って感じでざっくり理解すると良いと思います。
- // 分析モデルは現実空間の理解を表現したもので、設計モデルがそれに対する解決空間に含まれる、という理解。モデリングはどちらに対しても行なうかと。
- // 問題空間におけるモデリング = 「何をしたいか」「今どうであるか」
- // 解決空間におけるモデリング = 「何をどのようにするか」
- // 言葉の定義に明確に理解を求めるより先に進んで知識をアップデートしたほうが良いのでは
- // 問題空間だの解決空間だのってなんだろう的なことを脳内に軽くインデックスできたらもう先に行っちゃっていいんじゃないかと
- // 問題領域 -> ドメイン 解決領域 -> 今から作るシステム くらいでよいのでは？
- // 問題空間とは、そのドメインにおける解決すべき課題？ たとえば、P.42のオンライン販売の例だと、「買い物客に見せる商品カタログが必要」「買い物客からの注文を受け付けられないといけない」「販売代金の徴収する必要がある」「買い手に商品を発送できないといけない」が、問題空間？
- // ↑は細かすぎる。「こういうことが問題なんだ」くらいのおおまかなアプローチで良いのでは
- p.57 コアドメインは、視点によって変わり得る？
- ある視点ではマッピングサービスは汎用サブドメインであり、ある視点ではコアドメイン
- チームで一つのそれなりに大きなサービスを作る時には？視点を定める必要がある？
- コンテキストこそが重要。「アカウント」「口座」といったオブジェクトの名前ではなく、コンテキストに注目してオブジェクトの特徴を区別する。（P.59~60）
- コンテキストが異なるのに、同じような名前を持つオブジェクトや用語がある。 これらは同じ名前なのに異なる意味合いであることも多い。
- 例えば、銀行取引コンテキストにおける Account とは「口座」という意味であるが、 文学コンテキストにおいては Account とは「報告書」という意味になる。
- つまり "Account" という用語だけでは、その用語やオブジェクトが持つ特徴は理解できない。「その用語がどの境界付けられたコンテキストに含まれるのか」について注目することで、初めて Account という言葉の特徴を区別できるようになる。
- したがって、境界付けられたコンテキストは主として「言語的な境界」 を意味する。 どの境界線の内側に含まれるのかによって、同じ名前の用語でも、意味や特徴が変化する。
- 同じモデル内でも、一つの名前がライフサイクルの各段階で定義が変わる。（P.60～61）
- 例えば、書籍を出版するまでには、構想～執筆～出版～出荷 などの様々な段階がある。
- これら全ての段階における「書籍」という概念を、ひとつの「書籍」という言葉で表すことは困難である（書名、デザイン、草稿、在庫量など、段階ごとに「書籍」に必要な情報が変化する為）。
- このような場合、ライフサイクルのひとつの段階ごとに、異なる境界づけられたコンテキストを用いる。
- そして複数の境界づけられたコンテキストのそれぞれに異なる「書籍を表す型」を用意して、共通の識別子のみを共有することで、そのコンテキストでのニーズにマッチした「書籍」を扱えるようになる。
- 境界づけられたコンテキストは、ユビキタス言語の全貌を完全に表現出来るだけの大きさであるべき。多くても少なくてもいけない。（P.65）
- 境界付けられたコンテキストを、どのような単位でシステム化するのか？ (P.67-68)
- 一般的には 1つの境界付けられたコンテキストを Java なら Jar で、.Net なら dll で作り、システムを構成することが多い。
- ただし決まったやり方はなく、ドメインモデルだけしか含まなくてもよいし、1つのコンテキストに複数の Jar/dll を持ってもよい。やり方は自由だ。
- IntelliJ IDEAのような統合開発環境を使う場合は、境界づけられたコンテキスト単位でプロジェクトを作ることが多い。
- Visual Studio .NETを使う場合は、UI・アプリケーションサービス・ドメインモデルをそれぞれ別のプロジェクトとして管理し、ひとつのソリューションの配下に置くやりかたもある。
- 単一の境界づけられたコンテキストの作業は単一のチームが受け持つ（P.68）
- 複数のチームを1つのコンテキストに割り当ててしまうと、それぞれのチームが独自の解釈でユビキタス言語を作り始めて破綻するため。
-
P.66の「小型の境界づけられたコンテキストを作ってしまう問題は、注意深くモジュールを利用すれば回避できる」という一文が、よくわからない。モジュールを利用することで、適切なコンテキストが発見できる？:+1:
- // 後の章(9章)でモジュールが出てくるので、そのときに理解するしては
- // 多分、協会づけられたコンテキストが最終的にどういう形に落としこまれるのかがイメージできないと、そもそも小さく切ると困るということ自体が理解しにくいと思います
- // 境界付けられたコンテキストってそもそも一つのシステムにそうそういくつも現れる事はにないですね。
- // コンテキストごとに独立したシステムを作るのでなく、システム内のモジュールで分割することで、コンテキストの独立性を表現できる、とか?
- // p.66 「モジュールを適切に活用すれば、実際には単一の境界づけられたコンテキストにまとめてしまえると気づくだろう」
- // そうですね。ちょっと極端な言い方をすれば境界付けられたコンテキストとは全てAPI通信のみでやりとりする、みたいな運用も可能という事なので。
- // ちなみに、IDDDの主張では、最終的に1つの境界付らられたコンテキスト＝マイクロサービスの1アプリにするってのが原則っぽいです。(13章を見る感じ)そう考えるとあんまり細かくしすぎると困るよねというのも少しイメージが湧いてくると思います
- // 実際、必ずしも1アプリとはしないこともあるかなという感覚ですが、一旦この本ではそういう主張と理解しています
-
✅ P.67の「技術的なコンポーネントとの協調」にあるパッケージの切り分け例を見て、それぞれの境界づけられたコンテキストには、アプリケーションがあり、それらが単独で動くようにするのが理想？ 👍
- // 最終的に 1コンテキスト = 1システム・・・つまりマイクロサービスを目指す感じなので、それが理想なんだろうと思ってます。単独で起動するけど、協調動作するイメージのほうが
- // 13章の、境界づけれたコンテキストの統合の章を読むと結局同期か非同期かに別れてやると書かれている。実際は必ずしも1コンテキスト1アプリにしにくい時もあるんですが、一旦上記のやつをベースに考えて、あとは都度カスタムする具体の気持ちでいいと思います
- // チームもしくは1システムに複数コンテキストはやむを得ない場合だけにした方がよいと思います。ひとつのチームに複数コンテキストあると、 言語の切替も大変ですし、長くやるとひとつのコンテキストになってしまうのもそうですね。IDDDの例で一システムで複数コンテキストでてきますが、DDDを基にしないシステムの例でしたよね。たしか。本来は1チーム=1システム=コンテキストがよいですよ
-
✅ 『書籍のライフサイクルの段階ごとに、別の境界づけられたコンテキストを利用する。』という話があったが、各モデルのライフサイクルごとに境界付けられたコンテキストを作ると数がかなり多くなりそう。これは、「出版社」にとっての「書籍」が特に重要なモデルなので、そこのライフサイクルに着目したという感じなんでしょうか？？👍
- // 特に重要だから、ということではなく、それぞれのコンテキストで違う意味の「書籍」が出てくるのでそれぞれで作るんだよという話では
- // これってわかりやすい例ってだけでは？
- // デザイン用のシステム、翻訳用のシステムなど、それぞれのコンテキストで概念や解決すべき課題が違うんだから、一つのモデルだけでは対応できないよね、という例では
-
✅ 『複数の境界づけられたコンテキストのそれぞれに異なる「書籍を表す型」を用意して、共通の識別子のみを共有する』とあるが、永続化の際はどのようにするのか？DBに入れる場合は単一のレコードとなるのか？👍
- // 別れるというか、システムレベルで分かれる（マイクロサービス的な観点でも）ので、DBごと別れてIDだけ同じ、といった感じになると理解している
- // 境界があるので、当然別物です。
-
単一の境界づけられたコンテキストは単一のチームが受け持つべき、という根拠として、ユビキタス言語の解釈が分かれたり、ドメインモデルの修正のために議論が必要になるため、とあるが、これって一つのチーム内でも個人の解釈のずれとか発生するし、人数が増えれば一つのチームだってまとまりはなくなってしまうのでは？DDDにおける適切なチーム人数などがあるのでしょうか？
-
p.68 1コンテキストで1チーム？だとすると、各チームごとに自身にとってのコアドメインに注力せよ、他はサブドメインとみなして良い、ということだろうか
- 最適取得コンテキストは（その時点で）ビジネス全体のコアドメインで、他をサブドメインとして利用する
- 在庫コンテキストのチームにとっては在庫こそがコアドメイン？で、マッピングサービスをサブドメインとして利用する
- 早速コンテキスト-チームなのか、(サブ|コア)ドメイン-チームなのか、自分の中で揺らぎ始めた・・・
- 2章のサンプルでは以下のコンテキストが登場する。(P.70)
- コラボレーションコンテキスト
- 認証・アクセスコンテキスト
- アジャイルプロジェクト管理コンテキスト
- 第1章では、チームはセキュリティや権限の情報をコラボレーションモデルに組み込んでしまうミスを犯した。(P.71-72)
- セキュリティについての関心ごとをコアドメイン(コラボレーションモデル) に混ぜ込んだため、コアビジネスロジックのど真ん中で、開発者がクライアントの権限をチェックしてしまうといった混乱が生じた。(P.71-72)
- ※ 深く考えずにセキュリティ機能を実装してしまうと、個々のアプリケーションが自分のサイロの中に閉じこもってしまい、連携のないシステムとなってしまう。すると、両システムの利用者層がほぼ同じだとしても、システム間のユーザーの関連付けが簡単にはできなくなってしまう。(P.76)
- セキュリティについての関心ごとをコアドメイン(コラボレーションモデル) に混ぜ込んだため、コアビジネスロジックのど真ん中で、開発者がクライアントの権限をチェックしてしまうといった混乱が生じた。(P.71-72)
- この混乱を解決するため、「隔離されたコア」を目指してリファクタを実施。 コアドメインの「コラボレーションコンテキスト」から、 「認証・アクセスコンテキスト」を汎用サブドメインとして分離した。(P.73)
- その結果、それぞれに以下のようなメリットが生まれた。(P.73-74)
- 「認証・アクセスコンテキスト」を担当するチームは、その実装にあたって様々な戦略を導入できるようになった。 その実装がコアドメインと別れていることにより、とある顧客専用の認証の仕組みを作ることもできる。
- 「コラボレーションコンテキスト」を担当するチームは、コラボレーションモデルのオブジェクトの構成や挙動だけを実装すれば済むようになった(認証を意識しなくてもよい)。
- その後、コラボレーションシステム(CollabOvation) と連携する、
アジャイルプロジェクト管理アプリケーション(ProjectOvation) の開発を始めた。(P.78-79)
- 「アジャイルプロジェクト管理コンテキスト」の開発チームは、 利用者を『プロダクトオーナー』と『チームメンバー』と判断。(P.80)
- 『プロダクトオーナー』と『チームメンバー』はスクラムを実践するときにプロジェクトのメンバーが受け持つ ロール であるため、 「認証・アクセスコンテキスト」にそのユーザーやロールの管理を任せた。(P.80)
- その結果、プロダクトオーナーやチームメンバーといった情報を、 持つべき場所である「アジャイルプロジェクト管理コンテキスト」に持てるようになった。(P.80)
- システムをマイクロサービスとして扱うためには、『他の境界付けられたコンテキストに依存する度合いを制限しておく』必要がある。そうすれば連携先が落ちていても、一時的に使えなくなる部分があるかもしれないが、システム全体としては動き続けられる。(P.80-81)
- コラボレーションコンテキストのリファクタリングで、セキュリティのチェックをApplicationServiceのクライアント側でチェックさせてApplicationServiceとその内側（ドメインモデルとか）から排除していたが、例えば登録・更新画面の中の特定の項目だけ権限を見て更新可否を判定しないといけない場合はどうすればいいんだろう（そもそも権限が必要な項目だけメソッドも画面も分けなさいよって話だとは思いますが、、、）
- 「2.5 サンプルのコンテキスト＞コラボレーションコンテキスト の最後のあたり（P.76）」の『フォーラムやカレンダーなどが、それぞれ別のモデルになる。』～『そうではなく、このチームではモデルを1つのままにすることを選んだ。』という箇所は、モデルを１つの境界付けられたコンテキスト内で取り扱った、という理解でいいのか（フォーラムもカレンダーも１ドメインモデル、というのは流石に無理な感じがした）
- p.73 「純粋にコラボレーションを扱うドメインモデルを作りたいのに、まだセキュリティが邪魔している」
- コラボレーションをアプリケーションとして動かすに当たり、認証やロールの役割は必要そうに思う
- この場合、「認証済み or 適切なロールを持ったユーザーのみ、コラボレーションの機能を使える」というルールは、アプリケーション層で実装することになる？
- アプリケーション層で認証/ロールのチェックを行ってから、コラボレーションの呼び出しに入るイメージ？
- p.74〜75を見ると作りとしては↑っぽい
- ↑のルールはドメイン知識のアプリケーション層への流出にはならないのか？
- 「認証済み or 適切なロールを持ったユーザーのみ、コラボレーションの機能を使える」を担当するサービスを作るとして、そのサービスはどのコンテキスト/ドメインに所属するのか？
- アプリケーション層で認証/ロールのチェックを行ってから、コラボレーションの呼び出しに入るイメージ？
- ✅p.73 責務のレイヤ 👍 👍
- 「分割しても、各レイヤは同じモデルに残り続ける」
- 「各レイヤ」とは？
- 「同じモデルに残り続ける」のは、結局どういう構造が残り、その構造にはどんな問題が有るのか？
- // Evans p.470 のあたり？責務のレイヤ = 意思決定→ポリシー→業務→潜在能力という依存方向が示されている
- // Evans本読まないとわからないので飛ばしても良いのでは
- // ここで書いてるのは、別の責務を別のコンテキストに切り出すべきところを、同じコンテキストの低レベルレイヤに切り出すだけでは不十分、ということかなと思います。
- // 入っていてはいけないものが混ざっているのだから、レイヤーで分けるのではなくて、コンテキスト自体を分割したほうが良いよという話
- // ドメインの分割は垂直分割、機能抽象度の分割は水平分割。
- // 同一コンテキスト内で認証を責務のレイヤの1つとする
- // 認証をコアドメインとするコンテキストを新設する
- // この2つの話ということですね
- // 認証コンテキストを、コラボレーションコンテキストの中に入れるのか、外に追い出すのか、どちらが良いのか、ということが記載されている
- // ここでレイヤって表現を使っているのは、あくまで層。数ある責務のうちの一つとするか？という意味合いだと思います。
- 「分割しても、各レイヤは同じモデルに残り続ける」
- 2章のまとめが書かれている
- ドメイン、サブドメイン、境界づけられたコンテキスト
- 問題空間、解決空間について
- 境界づけられたコンテキストの適切な大きさ、何を含めるべきなのか
- ここに読んでて出てきた疑問を書く。
- // 自分の中でふわっとしていた部分が、違っていたものがあったが、腑に落ちる部分まで持っていけたのが良かった。今回はいろんな方の意見や解釈が飛び交っているところを読みながら考えられて、これは一人で読んでいてはできなかった
- // 翻訳の悲劇、って痛感。ちょっと思い浮かべているものが違うので、他の人の意見を聞いて「やっぱりそうだよね」となってよかった。原著版も読んだようが良さげ
- // 日本語だけだとわからないけど、原文だとわかるっていうのはよくある
- // 気になった単語を英語でググるとよくわかるっていうのはあるある
- // 3章やると2章よくわかる。コンテキストマッピングの話を理解するとコンテキストの理解が深まる。
- // 一回3章読み進めて2章に戻るのが良さげ？
- // 次回参加すると、今回の内容がより理解できますよ！
- //
- 3章やるとお得だよ
- もやっているところがわかってよかった
- // 今回の流れは良かった
- // どのへんで疑問点などを切ったら良いのか悩んだ。議論が止まって5秒くらい立ったら次、とかでも良さそう
- // 拾えなかった疑問点はどうする？
- // 今回を通して「分かったこと」が増えているはずなので、別の機会で「それでもわからん」やつを拾う会があってもよいのでは
- // IDDD読書会2週目などをやっても良いかも
- // 1週目の内容はテンプレートとして再利用できそう
- // 拾えなかった疑問用スレを作るので良さそう
- // 一旦2章分でチャンネルを作る
- // 全部だと流れるのでどうしても聞きたいやつを再掲する
- // 無理そうなので、掲示板・フォーラム的なサービス募集
- // 一旦2章分でチャンネルを作る
- 境界づけられたコンテキストは、松岡さんのブログこの記事を読んでおくと頭に入りやすいと思いました。:+1::+1::+1: