サブ資料④データモデル中心の設計

2023年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. 1 ページ サブ資料④：データモデル中⼼の設計（データ中⼼アプローチ） データ中⼼アプローチとは データ中⼼アプローチは、アプリケーションやシステムの開発において、データを中⼼に設計・ 開発を⾏うアプローチで、伝統的なシステム開発の⼿法として使⽤されることの多い。このアプ ローチでは、まずシステムで扱うデータの定義や関連性を明確にし、それに基づいてアプリケー ションの機能や処理を構築していく 三層スキーマモデル 三層スキーマモデルは、データベースの設計⼿法の⼀つであり、データベースの構造を3つの異 なるレベル（層）に分割する⽅法。これにより、データの保護、管理、変更の柔軟性を⾼めるこ とができる データの関連性に注⽬ データ中⼼アプローチの特徴 データ中⼼アプローチでは、まずデータの関連性を把握し、データ間の関係や依存関係を明確に する。これにより、データの整合性や⼀貫性を確保し、データモデルの設計やデータストアの構 築を⾏う データモデリング データ中⼼アプローチでは、データモデリングが重要な役割を果たす。データモデルはシステム の基盤となり、データの定義や関係性、属性などを表現し、適切なデータモデルを設計すること で、データの正確性や効率的な操作を実現する データの統合と再利⽤ データ中⼼アプローチでは、データの統合と再利⽤が重視し、共通のデータモデルやデータソー スを使⽤することで、データの⼀貫性を維持し、データの再利⽤性を⾼める。これにより、シス テム全体の保守性や拡張性が向上する データ中⼼アプローチの主な特徴は以下 引用元：https://monoist.itmedia.co.jp/mn/articles/0811/21/news164.html
2. 2 ページ Fict PAYのユースケース ユースケースは⼤きく分けて3つ MPM決済のテーブル設計 データを中⼼にテーブルを設計し、対応するデータモデルを作っていく << table >> カスタマ << table >> 店舗 << table >> 決済要求履歴 << table >> Fict PAY⼝座 << table >> 決済履歴 << table >> 決済代⾏業者 << table >> 加盟店 << table >> PG決済履歴 1 0..* 0..* 1 1..* 1 0..* 1
3. 3 ページ チャージのテーブル設計 データを中⼼にテーブルを設計し、対応するデータモデルを作っていく 1 0..* << table >> カスタマ << table >> ⾦融機関⽀店 << table >> チャージ要求履歴 << table >> Fict PAY⼝座 << table >> チャージ履歴 << table >> ⾦融機関⼝座 << table >> ⾦融機関 << table >> ⼝座振替履歴 1 0..* 0..* 1 0..* 1 1 0..*
4. 4 ページ インピーダンスミスマッチ データ中⼼アプローチではデータベースのテーブル構造や関連性が設計の中⼼になり、オブ ジェクト指向の設計から乖離してしまう場合があります。この状況を「インピーダンスミス マッチ」と呼ぶ。 インピーダンスミスマッチは、データベースとオブジェクト指向のプログラミング⾔語との 間で発⽣する設計上の不整合を指す。データベースはテーブルやリレーションシップに基づ いたデータの格納と検索を⾏う仕組みであり、⼀⽅、オブジェクト指向のプログラミング⾔ 語はオブジェクトとしての振る舞いや関連性に焦点を当てている モデル以外のオブジェクトの役割について データ中⼼アプローチにおける難点として、モデルの少なさが挙げられる。モデルが少ない と、オブジェクト指向の原則に従った設計が難しくなり、代わりにDTO（Data Transfer Object）が増える傾向がある。DTOはデータの転送や表⽰のためのオブジェクトであり、本来 のドメインモデルとは異なる役割を果たす（筈だが、事実上モデルのように扱われることも 少なくない）。 さらに、モデルが少ない分、モデルの代替処理がサービス層に集中することになる。そのた め、本来ならドメインモデルが担うべき処理が、サービス層に移⾏してしまうことで、設計 が複雑化したり、安定しにくくなる。これにより、設計の安定性が損なわれる可能性がある。 さらにデータ中⼼アプローチでは、データモデルやデータベースの設計に重点が置かれるた め、ビジネスロジックの設計が犠牲になることもある。これにより、設計の柔軟性や保守性 が低下する可能性がある。 （次ページへ続く） 送⾦のテーブル設計 データを中⼼にテーブルを設計し、対応するデータモデルを作っていく << table >> カスタマ << table >> 送⾦要求履歴 << table >> Fict PAY⼝座 << table >> 送⾦履歴 1 0..* 1 0..*
5. 5 ページ その他データ中⼼アプローチの難点 データ中⼼アプローチのその他の難点が以下 設計と実装との乖離: データ中⼼アプローチでは、データの関連性に焦点を当てて設計を⾏うが、 実装側の技術的な知識や経験に依存せずに設計を⾏うことは難しいことが多く、実装に⻑けた担 当者でないと、良い設計になりにくく、実装してみると問題や瑕疵が細部で浮き彫りになること がよくある。 モデルの少なさと全体のまとめ⽅: データ中⼼アプローチでは、モデルを中⼼に設計を進めるた め、プロジェクト全体で実装をどのようにまとめるかが重要になる。モデルの少なさや抽象度の 低さによって、実装⽅法や設計⽅針を統⼀することが難しくなりがちで、この点では、アーキテ クトやエンジニアの⼒量やセンスが重要な役割を果たす。 データモデルの複雑化: データ中⼼アプローチでは、データモデルがリレーショナルデータベー スのテーブル構造に基づいて設計されることが多いが、多くのテーブルと関連を持つと構造は複 雑になりがちである。 適切なバランスを⾒つけるためには、データ中⼼アプローチの利点を活かしつつ、ドメイン 駆動設計やオブジェクト指向の原則に則った設計を⼼掛ける必要があり、設計や実装の際に は、プロジェクトの要件や⽬標、チームのスキルセットやレベル等を考慮に⼊れ、適切な アーキテクチャを選択することが重要である。 ドメインモデル中⼼（ドメイン駆動設計）の難点 ドメインモデル中⼼設計には以下の難点がある 学習コスト: ドメインモデル中⼼設計は、従来のアプローチとは異なる概念やパターンを使⽤す るため、学習コストが⾼い場合が少なくない。ドメイン知識やDDD（ドメイン駆動設計）の原則 についての理解が必要であり、チーム全体での教育やトレーニングが必要となる場合がある。 複雑性の増加: ドメインモデル中⼼設計では、ドメインの複雑性をモデル化しようとするため、 モデル⾃体が複雑になる傾向がある。ドメインの概念や関連性を正確に反映しようとすると、開 発の複雑性やメンテナンスのコストが増加する可能性がある。 パフォーマンスの低下: ドメインモデル中⼼設計では、オブジェクト間の関連性を強調し、ドメ インの⼀貫性を保つことが重視されるが、この⼀貫性を保つためにはデータベースへのアクセス やオブジェクトの⽣成などのオーバーヘッドが発⽣する場合があり、パフォーマンスの低下が⽣ じる可能性がある。 開発時間の増加: ドメインモデル中⼼設計では、ドメインの概念やビジネスルールを反映するた めに、モデルの設計や実装に時間がかかる場合がある。また、ドメインの変更や追加要件に対応 するために、モデルの修正や再設計が必要になることがあり、これにより、開発時間が増加する 可能性がある。 （次ページへ続く）
6. 6 ページ ドメイン駆動設計とデータ中⼼アプローチの使い分け ドメイン駆動設計とデータ中⼼アプローチは、プロダクトの性質やプロジェクトの状況に よって使い分けることがあり、どちらのアプローチを選択するかは、以下のような要素に基 づいて判断されることがある。 プロダクトの複雑さ: プロダクトが複雑でドメイン知識が重要な場合、ビジネスの複雑さに対 応するためのモデルを作り上げることに焦点を当てているドメイン駆動設計が適していると いえる 変更の頻度: プロダクトの要件やビジネスルールが頻繁に変更される場合、ドメイン駆動設計 は柔軟性と変更への対応⼒を提供する。⼀⽅で変更が少なく安定したデータ操作が主体（特 定のDBへの参照や書き込みがメイン）の場合、データ中⼼アプローチが効果的といえる （次ページへ続く） （次ページへ続く） 技術的制約: ドメインモデル中⼼設計では、ドメインの意味を重視するために、特定の技術やフ レームワークに制約が⽣じることがあり、その制約に合わない場合、実装の複雑さや柔軟性の⽋ 如が⽣じる可能性がある。 ⼤規模開発におけるドメイン駆動設計（ドメインモデル中⼼設計） ドメイン駆動設計では、実装を意識しながら上流から設計を⾏うため、データ中⼼アプロー チに⽐べて設計と実装との隔たりが少なくなる傾向がある。 データ中⼼アプローチでは、主にデータベースのテーブル構造や関連性に基づいて設計を⾏ い、実装においてはその設計を反映させることが主眼となるが、ドメイン駆動設計では、ビ ジネスドメイン⾃体に焦点を当てながら設計を⾏うため、データの関連性だけでなく、ビジ ネスルールやドメインオブジェクトの振る舞いなども設計に反映されることになる。 また、ドメイン駆動設計では、ドメインモデルを中⼼に設計を進めることで、ビジネスドメ インを正確にモデル化し、そのモデルを実際の実装に反映させることが重要になる。そのた め、設計段階から実装を意識することで、設計と実装の隔たりが少なくなる。また、ドメイ ン駆動設計ではドメインエキスパートや開発者との積極的なコミュニケーションや協⼒が重 要となるため、設計と実装の間における認識のズレや抜け漏れも少なくなる傾向がある。 ドメイン駆動設計は設計と実装の間のギャップを埋める⼿法として効果的であり、設計と実 装の⼀体性を⾼めることができる ⼀⽅で、⼤規模開発で選択されることの多いウォーターフォール開発では、フェーズごとに 厳格な⼿順を踏むため、各フェーズでの要件や設計の変更は困難であり、ドメイン駆動設計 のような柔軟性を持ったアプローチとは相性が良くないと⾔えるが、 例えば、ウォーターフォール開発の要件定義フェーズで⼗分なドメイン知識を収集し、それ を基にしたドメインモデルを作成する等、ウォーターフォールにドメイン駆動設計の要素を 取り⼊れることは可能といえる
7. 7 ページ プロジェクトの期間とリソース: プロジェクトの時間やリソースが制約されている場合、デー タ中⼼アプローチは開発の迅速な進⾏を可能にする。データベースアクセスに重点を置くこ とで、開発の効率性を⾼めることができる チームのスキルと経験: チームメンバーのオブジェクト指向やドメイン駆動設計に関するスキ ルや経験によっても選択が影響を受けることがある。適切な訓練やサポートがなければ、ド メイン駆動設計の導⼊は困難であることが少なくない。 その他、プロダクトの性格やプロジェクトの状況を考慮し、ドメイン駆動設計とデータ中⼼ アプローチを適切に組み合わせることもあります。例えば、データ中⼼アプローチをベース にしながら、⼀部の重要なドメインに対してはドメイン駆動設計を導⼊するというアプロー チなどが挙げられる