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では、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
traitで簡単にDCIを実装する - じゅんいち☆かとうの技術日誌
モデルの表現方法の一つとしてDCIの実装方法を、いろいろと模索しています。 暗黙的型変換と型クラスを使ったDCIがよいと説明しましたが、traitだけでもっと簡単に実現できないか考えてみました(この方法はLean Architectureにも紹介されている実装方式です)。 traitで仕様を表現する traitは、仕様を表現するためのインターフェイスとしても使えるし、他のクラスなどに合成するための、再利用可能な実装(部分クラスなどと言われることがある)としても使えます。 DCIとは直接関係ない話ですが、まずtraitのインターフェイス的な使い方からいきます。 では、お決まりの銀行口座で説明(好きやなーw)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 銀行口座エンティティ // 不変条件: 残高の量は負数であってはならな
JavaScriptでDCI的なものを実装してみた例
gistfile1.txt �U#^ U ��2^ U // 銀行口座 var BankAccount = function (balance) { this.balance = balance; }; BankAccount.prototype.increase = function (money) { this.balance += money; }; BankAccount.prototype.decrease = function (money) { this.balance -= money; }; // ロール: 送信側 var Sender = function () {}; Sender.prototype.send = function (money, to) { this.decrease(money); to.onReceived(money, this); }; /
ドメインを巡るお話 | Uzzu::Blog
Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
分かった気になる DCI 、ロミオとジュリエット編 Romeo & Juliette with DCI
00-actor.rb ��i V �� V # 役者クラス # # say: 役者は声を発する事ができる。 class Actor def say(words) puts words end end 01-romeo.rb ��t V 7 V # ロミオ役 # # ロミオはジュリエットの問いかけに当惑する # "もっと聞こうか、それとも返事をしようか？" module Romeo def hesitate say "Shall I hear more, or shall I speak at this?" end end 02-juliette.rb 0He V �5� V # ジュリエット役 # # ジュリエットはロミオに問いかけ、名を捨てるように請う # 1. # あぁロミオ、ロミオ！ どうして貴方は<わが一族の敵である>ロミオなの？ # 貴方の父を否定し、名前を拒
DCI (Data Context Interaction)
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 今回は「Data Context Interaction (DCI)」として用意した以下のスライドを説明します。 オブジェクト・モデリングの問題点の一つに、ユースケースからドメイン・オブジェクトへ真面目に責務の分散配備をしていくと、ドメイン・オブジェクトの実現が非常に重たくなってしまうという問題があります。 ドメイン・モデルそのものに由来するドメイン・ロジックをドメイン・オブジェクトで実現するのは、本来のオブジェクト指向の趣旨にも則っており問題ありません。 論点となるのはユースケース由来のアプリケーション・ロジック。このアプリケーション・ロジックを、(1
DCI を考える #2 - 鳩舎
追記 まじで鳩さんのスライドでDCIについて理解したつもりになるの危険だからやめた方がいいです。せめて d.hatena.ne.jp/digitalsoul/20… を読みましょう。DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイムです— Naoto Takai (@takai) December 27, 2012 ということで、以下の内容はすべて間違いである可能性が高いです。 元記事 これまでのあらすじ: ActiveStrategy はイマイチなアプローチだよね。 文脈によって可能な挙動が変わり、モデルは基本的にデータのみを持つことでクリーンな状態を保とうといっているのに、便利な include を提供する ActiveStrategy はやはりイマイチなアプローチで、挙動の切り分けが容易になるのはいいことだけれど、それって今までの include 地獄から何も
2018年版無料で使えるiPad/iPhoneサブディスプレイ化アプリ比較 - Resilient Mind
先日、ホームビデオを作っていた時のこと。 NASからローカルに動画ファイルをコピーしようとしたら、「残り６時間」とか言われてしまいました。...
DCIアーキテクチャについて勉強してきた #あーだCoder - 亀岡的プログラマ日記
第二回あーだCoderをやってきました。 - #あーだCoder 第二回 - connpass 解説すると、あーだCoderというのは僕と@irofさんの間で勝手に盛り上がっていつの間にかconnpassたったのでとりあえずやってみるかと始まったコード中心にモデル実装なんかを語る場。 今回は割りとじっくりとコードを見て、それから解説をしてもらいました。 特に興味深かったのが@ktz_aliasさんのコード。 - Codersation/TDDBC_VendorMachine/ktz_alias at master · posaunehm/Codersation · GitHub Data Context Interaction : DCIアーキテクチャ、というのがあるらしくて（本気で初耳）、それについてつらつらと議論して（というか教授してもらって）いました。 とりあえず、札幌Ruby会議で
DCIアーキテクチャについて語ってみるよ - uehaj's blog
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
ScalaによるDCIアーキテクチャ：ローンシンジケート再考 - Digital Romanticism
GroovyによるDCIアーキテクチャのサンプル実装で明らかになった２つの問題点をScalaによって解決する。 導入 前回のエントリでは、DCIアーキテクチャの構想に従った実装を示しつつ、言語的な制約から来る問題点を２つ提示しました。以下に再掲します。 ミックスインしたロールクラスにキャストすることができないため、ロールクラスを使用する際に型の安全性が確保されていない。追記：asTypeを使用することで、ミックスインしたクラスへのキャストが可能です。uehaj様より指摘を頂きました。（2010/06/04） ロールクラスが定められたふるまいを実行するためにはデータ構造についての知識が必要だが、それを静的に保証することができていない。 これらはいずれも型の安全性に関する問題で、アーキテクチャの問題というよりは言語仕様の問題です。そこで今回はScalaを使用し、これらの問題をトレイトと抽象メン
DCIアーキテクチャの実装：ローンシンジケート - Digital Romanticism
DCIアーキテクチャの概要を整理した上で、DDDに登場するローンシンジケートを用いたサンプル実装を示す。 DCIアーキテクチャの概要 Trygve Reenskaug氏とJames O. Coplien氏によるDCIアーキテクチャの構想は、「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」にて解説されています。ここでは、オブジェクト指向の本質が人間のメンタルモデルを捉えることにあるとした上で、オブジェクト指向の問題点とその解決方法が語られます。オブジェクト指向の問題とされているのは、構造を捉えることに長けている反面、ふるまいをとらえることが苦手であるという点です。具体的には、特定のふるまいをどのクラスにおくべきか悩んだり、エンティティクラスが大量のメソッドで肥大化してしまうといったことが挙げられるでしょう。 この問題に対する解決は、オブ
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はエンドユーザのロールに関する認識モデルとロール間の関係を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - DCI/scaladci: Exploring the DCI paradigm in Scala
型とか微妙になってるけど多分こんなん
T6-501多言語パラダイムによる実装手法に関するフォローアップ - 荒井省三のBlog - Site Home - MSDN Blogs