blog新米webエンジニアによる技術ブログ。続いて第2回も無事に開催することができました。今回は書籍の前に目を通したが、最初に概要を掴んでから書籍に入れるので効果的。今後もこの進め方でいきたい。この章はボリュームが小さくて助かった。学習メモ第2章で「境界づけられたコンテキスト」を学んだが、「コンテキストマップ」は複数の「境界づけられたコンテキスト」の関係を俯瞰する図となる。抽出したコンテキストを線で結び、互いの関係性を整理していくイメージ。つのコンテキスト間にはどちらかが上流(Upstream)でどちらかが下流(Downstream)という関係がある。プロジェクトの現状を示す図。あって欲しいという将来の図ではない。コンテキストマップを描くことによって、システム間の関係を適切に把握できるメリットがあります。DDDチームは既存システムとの連携方法を把握でき、他チームとのコミュケーションの必要性を判断できるようになります。コンテキストマップはアーキテクチャ図というよりも、チーム間のコミュケーション関係を示す図の意味合いが強くなります。コンテキストマップは組織間の問題を見つけ出せる唯一のドキュメントとなるため、プロジェクトの成功に不可欠といわれています。境界づけられたコンテキスト間の関係には、いくつか名前の付いた種類がある。解説されているように、まず大分類としてチーム間の関係を示す「組織パターン」データとプログラムの連携方法を示す「統合パターン」に分けて考えると理解しやすい。記法では三角の警告アイコンを記載する。なさそう競合ポイントはどうやって見つけるのか書籍に出てきた図が(ひょうたん型になっていて)恣意的な感じが...リモートモデル、ローカルモデルとかのくだりがよくわからない自立性を確保するには、依存するオブジェクトの状態をローカルシステム側に保持しておけばいい。依存するオブジェクト全体をキャッシュしておけばいいと考える人もいるかもしれない。DDDでは、この考え方は一般的ではない。その代わりに、ローカルのドメインオブジェクトを作って外部のモデルをそれに変換し、ローカルのモデルに必要な最小限の状態だけを保持する。レスポンスを加工してアプリ内で使うためのモデルに変換する、というのはここに記載されたことそのものズバリな気がする。見つけたものをどんどん追加していきます。入門2日め、という位置づけ。集約)メモが滞ってる。第10章「集約」のメモを。Playgroundがリリースされました月別アーカイブはてなブログをはじめよう!dackdiveさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。