DDD超入門(前編) - Domain-Driven Designの概要 - エンタープライズギークス (Enterprise Geeks)
今回から2回に分けて、Domain-Driven Design（ドメイン駆動設計。略してDDD）を紹介する。 DDDとは、Eric Evans氏が2000年代初頭から提唱しているソフトウェア設計手法で、機能中心ではなくドメイン（ビジネス上の関心領域）に設計の重心を置いたオブジェクト指向設計手法の1つである。 前編の今回はまずDDDの概要にふれ、次回は後編としてDDDの適用Stepについて簡単に紹介する。 DDDの前身 DDDは、Martin Fowler氏が以下の書籍『PoEAA（Patterns of Enterprise Application Architecture）』の中で分類している以下の3つのロジックパターンの内「ドメインモデル」の流れをくんでいる。 エンタープライズアプリケーションアーキテクチャパターン 作者: マーチン・ファウラー出版社/メーカー: 翔泳社発売日: 201
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
