Object Design Rough Talks というイベントを開催して、Points of View という内容で話ました。 いろんな意味で面白いイベントだったので、詳細なまとめはまたこんど。
Object Design Rough Talks #1 - 鳩舎
Object Design Rough Talks というイベントを開催して、Points of View という内容で話ました。 いろんな意味で面白いイベントだったので、詳細なまとめはまたこんど。
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
今年も1月終わったし DCI の話しようか - Qiita
いままで色々 Rails 向けに DCI を実現する gem を作ってきたわけですが(Dicer / BluePrint)、今年もまた新しく考えなおして Rails 向けに DCI を実現する gem を書きました。毎年毎年ほんとよくやりますね。 今年は何気なく作り続けて、いままで活用されていなかった uninclude という gem をついに使って DCI をやってみました。 uninclude にてついては特に解説することもないというか、名は体を表すということで『#unextend や #uninclude を Ruby で使えるようになる』という gem です。Refinements などでも実現可能なのですが、Refinements はファイルごとだったりでスコープがわかりづらくなるので使っていません。 RockMotive 2015年の DCI on Ruby は RockMo
『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
分かった気になる 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)
パターンに機能と型を取り戻す アジャイルにおいてアーキテクチャを表現する DCI James O. Coplien （著） 和智 右桂 Growth xPartners Inc. （翻訳） Copyright c 2010 Gertrud & Cope. All rights reserved. はじめに 本稿は James O. Coplien 氏の論文「Restoring Function and Form to Patterns」（http: //www.software-architect.co.uk/slides/sa10-JimCoplien Patterns.pdf）の全文を、氏 の許可を得て翻訳したものです。 要約 15 年以上前、我々はソフトウェア・パターンの規範のための基盤を築いた。—この規範は後に長 いこと、ソフトウェア・アーキテクチャにとっての中心になったものであ
DCI Talk by James Copelien - Kentaro Kuribayashi's blog
James Coplien(@jcoplien), thankfully, gave us a talk titled "DCI and Ruby — the current DCI language of choice". Which was arranged by @kakutani to, I guess, let us, Japanese Rubyists, know about true DCI concept given by its main advocator. Thanks guys for the great opportunity. Here, I'll wrap up what I got from today's talk. It probablly includes many misunderstanding, though. It doesn't precis
DCI meetup に参加しました #dcimeetup - bekkou68 の日記
きっかけ DCI という言葉をチラチラと聞いていたのですが、正体がつかめなくて気になっていたので DCI meetup に参加してきました。 お話しを聞いて いろいろと自信がないですが、理解を自分の言葉にしてみました。ちゃんとわかっているわけではなく、断片的に何となくわかったような気になっているだけです。少しでもアウトプットしてみます。間違っている点などありましたらツッコミいただければと思います。 以下を書くにあたって、#dcimeetup の TL と『DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism』を参考にさせていただきました。ありがとうございます！ DCI は Data Context Intraction の略 DCI の目的はエンドユーザとコンピュータとのメンタルモデルを一致させるこ
rubyでDCIを実装するなら移譲でいいんじゃないか？
以下の記事を読むと、DCIはRubyでは遅いという指摘があったので、移譲で 実装すればいいと思ったので、下記記事のサンプルコードをもとに、 send/method_missing, forwardable, delegateを使ったサンプルを書いて みました。 “DCI”in Ruby is completely broken ※ 上記記事では移譲を使ったアプローチにも言及しているし、改善するには 頑張らないといけないという程度の話と認識しました。 ■ ベンチマークの結果（ruby 1.9.3p194） without dci 3024223.4 (±1.7%) i/s - 15139474 in 5.007655s with dci 768491.0 (±6.6%) i/s - 3833440 in 5.011732s with dci(send) 1586461.1 (±2.1%) i
DCIアーキテクチャによるWebアプリケーションの実装：ドメインレイヤ - Digital Romanticism
DCIアーキテクチャを用いて、割り勘の計算を行うWebアプリケーションを実装する。 導入 前回のエントリでは、DCIアーキテクチャの思想に基づき、試験的にドメインレイヤを実装しました。今回からはその発展編として、DCIアーキテクチャによるWebアプリケーションについて、数回に渡り検討していきます。言語はScala、WebフレームワークとしてはWicketを使用します。なお、データは今のところメモリに保持することとし、永続化層の実装については後日検討することにします。初回の今回はドメイン層をターゲットとして設計について考えていきます。 割り勘アプリケーション 要件 これから実装していくのは「割り勘アプリケーション」です。前回でも使用していたSharePieの概念を身近な形で引き継いだものですね。使用される状況は以下のようなものを想定しています。 飲み会の清算は等分ではなく、役職に応じて「傾斜
DCI を考える #2 - 鳩舎
追記 まじで鳩さんのスライドでDCIについて理解したつもりになるの危険だからやめた方がいいです。せめて d.hatena.ne.jp/digitalsoul/20… を読みましょう。DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイムです— Naoto Takai (@takai) December 27, 2012 ということで、以下の内容はすべて間違いである可能性が高いです。 元記事 これまでのあらすじ: ActiveStrategy はイマイチなアプローチだよね。 文脈によって可能な挙動が変わり、モデルは基本的にデータのみを持つことでクリーンな状態を保とうといっているのに、便利な include を提供する ActiveStrategy はやはりイマイチなアプローチで、挙動の切り分けが容易になるのはいいことだけれど、それって今までの include 地獄から何も
DCI を考える - 鳩舎
追記 まじで鳩さんのスライドでDCIについて理解したつもりになるの危険だからやめた方がいいです。せめて d.hatena.ne.jp/digitalsoul/20… を読みましょう。DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイムです— Naoto Takai (@takai) December 27, 2012 ということで、以下の内容はすべて間違いである可能性が高いです。 元記事 Data - Context - Interaction いわゆる DCI が最近の人気らしい。 DCI そのものの説明をこのエントリでする気はないので、 Sapporo Ruby Kaigi の角谷さんのプレゼンなどを見るとよい。 Rails の場合、 Data はまぁ ActiveRecord / Mongoid などのいわゆる MVC におけるモデル、であっていると思う。これに
beとdoを分離する - ✘╹◡╹✘
http://clean-ruby.com/ The classes that we begin to define should represent data or model the behavior of the data object, but *not both* 札幌でおっさんっぽい人達がDCI、DCIって言って盛り上がってたから、最近DCIについて触れるためにClean Rubyって本をゆっくり読んでみてたんだけど、筆者がこういう主張をしてて、ナルホディウス、ナルホディウスですぞーって思ってた。どう在るかというのと、どう振舞うかというのは、それぞれ別の箇所でまとめて定義されているべきとのこと。実装としては、Userみたいなclassがデータ(=どう在るか:be)を定義していて、XXXableとかXXXerみたいなmoduleが処理(=どう振る舞うか:do)を定義していて、Us
DCIが面白い件 - ヽ( ・∀・)ノくまくまー(2010-05-12)
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ディースィーアイかと思ったらなんだか変なことになった思考実験.rb
DCI with Ruby
GitHub - vsavkin/DCI-Sample: A sample application illustrating the Data Context Interaction paradigm (in Ruby)