DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。（原文公開日：2009年3月20日） 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
DCI (Data Context Interaction)
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 今回は「Data Context Interaction (DCI)」として用意した以下のスライドを説明します。 オブジェクト・モデリングの問題点の一つに、ユースケースからドメイン・オブジェクトへ真面目に責務の分散配備をしていくと、ドメイン・オブジェクトの実現が非常に重たくなってしまうという問題があります。 ドメイン・モデルそのものに由来するドメイン・ロジックをドメイン・オブジェクトで実現するのは、本来のオブジェクト指向の趣旨にも則っており問題ありません。 論点となるのはユースケース由来のアプリケーション・ロジック。このアプリケーション・ロジックを、(1
『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
