DCIアーキテクチャへの違和感から見えてくるユースケースDSL - 石橋秀仁(zerobase)書き散らす
DCIとDDD DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticismを読んだり、DCI meetup w/ @jcoplien for Rubyistsに参加したりして、DCIアーキテクチャについて考えてきた。 DCIはメッセージパッシング指向だ。そのSmalltalk的なオブジェクト指向の原理はいいけど、実装が嫌だ。 そもそも、DCIアーキテクチャ提唱の目的は、メンタルモデルのセマンティクス・ギャップを埋めることだ。DDDの「ユビキタス言語」も、メンタルモデルのセマンティクス・ギャップを埋めるための要素であり手法だ。だから、ふつうにDDD（ドメイン駆動設計）をやればいいと思った。 DCIへの疑問 DCIでは、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
レイヤとデータからみるDCIアーキテクチャの実装 - Digital Romanticism
DCIアーキテクチャに従ってCRUDアプリケーションを実装する際のポイントを整理する。 導入 Trygve Reenskaug氏によって提唱され、主にJames O. Coplien氏によって理論的な確立と普及が進められているDCIアーキテクチャですが、まだ実装事例はそれほど多くありません。このブログではこれまで「割り勘」を題材にDCIアーキテクチャに基づくCRUDアプリケーションを実装しつつ、アプリケーションの全体像について考察してきました。今回は割り勘アプリケーションをふりかえりつつ、もう少し実装の詳細について考えていきます。 アプリケーションレイヤ アプリケーションレイヤとはDDDにおいて説明されているレイヤの１つで、ドメインレイヤを薄くラップし、タスクに応じて適切なドメインロジックの呼び出しを行うという責務を与えられています。 アクションクラス 具体例として、割り勘アプリケーション
DCIによるWebアプリケーション - ２：アーキテクチャ - Digital Romanticism
前回ドメインレイヤを実装した「割り勘アプリケーション」のプレゼンテーションレイヤを実装し、全体的なアーキテクチャについて考察する。 導入 前回のエントリでは、DCIアーキテクチャの概念に従って「割り勘アプリケーション」のドメインレイヤを実装しました。その後、Wicketを使用してプレゼンテーションレイヤを実装し、「企画」から「会計」までを一通り動かすことができるようにしました。今回はこの作業を通じて得られたDCIアーキテクチャにおける考慮事項について解説していきます。（ソースコードはこちらで公開しています。） ※ 配色については、こちらのサイトを参考にさせて頂きました。 DCIとMVC フロントを含めた基本的なアーキテクチャを以下に示します。 PageクラスとActionクラスの責務分割については、「Pageクラスはコンポーネントの生成と画面遷移のみを行い、ContextおよびReposi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
