https://uga-box.hatenablog.com/entry/2024/07/11/000000

「ドメイン駆動設計をはじめよう」という本を読み始めた

第四部の「他の方法論や設計技法との関係」について読書メモを書いておく

他の方法論や設計技法との関係

この第四部は、DDDとその他の方法論と絡めて設計を検討する話

各章の見出しは以下

マイクロサービスは、区切られた文脈とよく関連づけられるアーキテクチャで親和性はあるが、全く一緒とはいえない

マイクロサービスの方が粒度が小さく、区切られた文脈になりうるが、すべての区切られた文脈がマクロサービスではない

あまりにも細かく分割しすぎると認知負荷が上がり、手に負えなくなってくるので区切るバランスが重要

詳細は割愛

イベント駆動型アーキテクチャは、その名の通りイベント基づいて設計するアーキテクチャ

DDDでも事業活動を業務イベントという「イベントソーシング」として表現するので、これと同じと思われるかもしれないがそうではない

イベント駆動型アーキテクチャはサービス間の通信方法で、システムの他のコンポーネントとの連携を意図した方法だが、イベントソーシングは、サービス内部の実装方法で、内部の状態変化を表現するものなのでシステムの他のコンポーネントの連携は意図していない

ただ、区切られた文脈の公開インターフェースを設計する上での手段にはなりうる

詳細は割愛

業務系データではなく、分析系データの場合にどうドメイン駆動設計を活用するかの話

分析系データとは、蓄積されたデータを活用して、以下の方法についての洞察力を与えてくれるもの

業務データと違ってトランザクション処理は目的でもないし、ヒトやモノの管理に焦点を合わせたテーブル構造でもなく、事業活動に焦点を合わせ、事実テーブルと特性テーブルでデータを構造化する

事実は業務プロセスや行動を表現していて、特性は事実の性質や状態を表現する

例えば、事実（案件の完了）に対して、特性（担当者、カテゴリー、顧客、日付、エスカレーション状態）のような関係

事実レコードと特性レコードの関係は多対１で、１つ特性レコードに対して、多数の事実レコードが存在するスキーマ（Star Schema）や、特性をさらに細分化して多段階にしたスキーマがよく使われる（Snowwflake Schema）

分析系データは業務データ以外にもイベントメッセージのストリーム、ログファイルなどに基づいている

それぞれを直接取り込むのではなく、すべての分析系データに変換しておく場所をデータウェアハウスという

ただこれは、すべてのデータを単一のモデルに押し込むことになるし、業務系データと密結合になりやすいので破綻しやすい

また、データを分析系データに変換する前の生の状態で一旦保管しておき（データレイク）、そこから変換してデータウェアハウスに保存する方法もある

ただこれも、データが増えてくると生のデータが乱雑で扱いづらいものになってしまう

データウェアハウスやデータレイクはいわゆるモノリシックな考え方なので、ドメイン駆動設計のように文脈で区切って構築する方が良いと考えられる

この考えをもとにした分析系のアーキテクチャをデータメッシュという

基本原則は以下

重要なことは境界を明確にして、実装の詳細をカプセル化して、適切な公開インターフェースを定義すること