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では、「オブジェクトのアイデンティティ」にこだわりすぎていることで、アーキテクチャが複雑になって
extend / unextend を使った際の問題 - 鳩舎
uninclude を使って DCI をやるとして、現実的なのかという話になってくるのだけど、これがまた曲者だなぁと思っていたり。 コード的な可読性とかは一旦置いといて、速度はどうなのってことだけとりあえず考えた。 現状、 extend 及び unextend はそれを実行した瞬間に Ruby VM 上のメソッドキャッシュを全部飛ばす(これ認識あってるかな、多分あってる)全部というのは本当に全部で、 class A; end class B; end module C; end a = A.new b = B.new b.extend(C) としたとき、 A のクラスのメソッドキャッシュすら飛ぶはず(認識違いかもしれないけど)。これは結構バカにならなくて、問題だと思う。で、 SimpleDelegator や Forwardable を使ってラッパーをはさめばいいだろうという結論にいたって
『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
PCCAA清書2
このノートでは、個人で携帯可能な情報操作機器の出現と、子供たちと大人たちがその利用によって受ける影響についての考察を行ないます。まるで空想科学小説のようだと思われるでしょうけれど、現在の世の中の小型化と低価格化の趨勢を思えば、ここで議論される多くの概念が近いうちに現実化することは、ほぼ確実なことです。 長年にわたり、技術を活用して社会問題を救おうとするのがひとつの伝統でした:「スラムが問題？ならば低コストの住宅を作りましょう！」「テレビを買う余裕がない？では欲しい時に買えるように、安価なものを作りましょう。たとえ支払いが済む前に壊れるとしてもね！」「子供たちは学んでいないし、教育コストも高すぎる？では、あなたの子供たちがテストに合格するのを保証する、教育メカを作りましょう！」 残念ながら、これらの「救い」のほとんどは、単にサビの上にペンキを塗っているだけです。最初の問題の原因は残されたまま
Use-Case 2.0 e-Book
Use-Case 2.0 re-focuses on the essentials and offers a slimmed down, leaner way of working, for software teams seeking the benefits of iterative, incremental development at an enterprise level. use-case 2.0 provides an adaptable, lean and scalable approach Use-Case 2.0 is ideal to work with Agile frameworks like Scrum at Scale, Disciplined Agile and SAFe. You see the big picture and help your team
DCIの疑問点をまとめる - yojikのlog
以下勉強会(DCI hansei meetup)用のメモです。 自分の立場 問題意識は理解できる。しかしこの問題は以前から理解されていたものであり、それぞれの方法論等で常に問題になっているものである。DCIで解決策として示されているものが、それ以外の方法に比べて特にすぐれているとは思えない。 DCIに関する自分の理解 DCIとは スピリチュアルなことを別とすればMVCと同様のアーキテクチャパターン。 http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 コンテキスト ユーザーとの相互作用があるソフトウェアをつくる際には、ユーザの意図とソフトウェアの内部で起きていることを同期させる必要がある。具体的にはGUIアプリケーションの構築時など。 DCIが解決しようとしている問題 従来のMVVの道具(オブジェクト指向の道具)では、、いろいろな不具
ドメイン居酒屋に参加した - おもしろwebサービス開発日記
最近DDDやDCIなどのキーワードが気になっているのですが、そんな折に下記のような勉強会が開かれるのを知ったので参加してみました。 10月26日 豆ナイト：ドメイン居酒屋～モデル駆動プログラミングの集い～(東京都) DDDやDCIが気になっているのは、「Railsで “skinny controller, fat model” を意識して書くとモデルにメソッドが集まりまくる」のをなんとかしたいなと思っていて、その解決方法としてDDDやDCIが有効なのではないかと考えているからです。 内容的には、最初に発表された増田さんのスモールオブジェクトプログラミングの話がとても響きました。このスライドで書かれているアンチパターン「ひとつの部品(クラス)がいろいろ知っていて、なんでもやりたがる」ってまさにRailsのmodelなんじゃないのかなあ。 ちいさなオブジェクトでドメインモデルを組み立てる fr
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
Object-Oriented File Importing and Parsing
The following is an example of file importing and parsing in Ruby using object-oriented techniques such as duck typing and dependency injection. Inject a CSVParser dependency into a the Importer # app/controllers/contact_imports_controller.rb: class ContactImportsController < ApplicationController def new @importer = Importer.new end def create @importer = Importer.new( parser: CSVParser.new(impor
artima - The DCI Architecture: A New Vision of Object-Oriented Programming
Object-oriented programming was supposed to unify the perspectives of the programmer and the end user in computer code: a boon both to usability and program comprehension. While objects capture structure well, they fail to capture system action. DCI is a vision to capture the end user cognitive model of roles and interactions between them. Objects are principally about people and their mental mode
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DCI and Rails, lessons learnt
GitHub - rosylilly/uninclude: Implement Module#uninclude and Object#unextend
DCI の話をした - 鳩舎