「単独主キー専用環境」と賢くつきあうために - 設計者の発言
「ORマッピングの功罪」の続きである。複合主キーが忌避される開発環境について、もう少しつっこんで考えてみたい。まともなORマッパーであればふつうに複合主キーを扱えるのにもかかわらず、ORマッパー上で組み立てられた開発環境ではしばしば複合主キーが非推奨とされる。なぜなのか。 その種の開発環境において、データ要件を「オブジェクト（クラス）構造」として認識し、それをRDBに落とし込むといった設計スタイルを実践することが前提になっているためだ。個別案件においてOOP（オブジェクト指向プログラミング）を使う余地が大きい開発環境ほど、この傾向が強まる。その独特なスタイルは、かつてはOOA/OODと呼ばれ、今ではDDDと名前を変えつつも(*1)、OOP使いの間で根強い人気がある。 その枠組みにおいてクラスの実際値（オブジェクト）は、RDBテーブルのレコードとして永続化（保存）されることになる。オブジェク
ドメイン駆動設計 実践のための原則を4つ考えてみた - HITORIGOTO
『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。 なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。 DDD本とドメイン駆動設計 DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
