A Life in Shinjuku.

このブログを検索

投稿テスト

3月 11, 2006

リンクを取得
Facebook
Twitter
Pinterest
メール
他のアプリ

投稿テスト。

リンクを取得
Facebook
Twitter
Pinterest
メール
他のアプリ

QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ

アーキテクチャパネルディスカッションとラウンジ・ビアパーティでの雑談から、主にDDDに関して興味深かった話をいくつか。聞き取り能力は低いので抜けている部分もあると思いますがご容赦を。ビジネス的な有用性はどこにあるのか Evans氏発言要旨経営層など意思決定を行う人たちに対して、ドメイン駆動設計の有用性をどう訴えかけるのか？という問いに対して、Evans氏は主にコアドメインへの注力によって競争上の優位、市場優位につなげる部分を強調。ここから一段階細かいレベルとして、ビジネスパーソンにとって理解できるソフトウェアへと進んでいくとのこと。ただし、常に労力に見合う価値が得られるわけではないことも忘れずに付加。雑感この質問はなかなか難しく、聴衆の反応も微妙なものだったように思う。これは、DDDをオブジェクト指向設計方法論として受け取っている人が多く、こうした部分の有用性についての回答を期待していたものの、Evans氏は主にPartⅣの戦略的設計（Strategic Design）の有用性について語ったために、ギャップが生じたためだと思う。 DDDは一読するとオブジェクト指向分析・設計方法論に関する本のようにも見えるが、実際はOOに直接結びついているわけではない。ドメインを中心に設計をする上で都合の良いパラダイムが現状ではオブジェクトパラダイムであるために、実現方法を記した部分（PartⅡ、PartⅢ）がオブジェクト指向設計に沿った形で書かれているにすぎない。DDDにとって根本的に重要なのはOOではなく、その名が示すとおり「ドメイン」へのフォーカスだ。この点を踏まえたなら、コアドメインへの注力はシステム/ソフトウェア全体をドメインの観点から区分するという意味で、まさに大きな意思決定を行うレベルでのドメイン駆動設計そのものだということが理解できると思う。 OO話がなかったのは…残念でした。ドメインエキスパートをどうやって巻き込むのか Evans氏発言要旨ドメインエキスパートとの最初のミーティングで、「あなたが最も難しく、面倒だと感じるのはどういった部分なのか？」「安眠を妨げるような問題はないか？」とたずねて、具体的なシナリオをあげてもらう。細かい問題は後で決めれば良い。画面項目の最大長や色などを聞くのはナンセンスで、ただでさえ忙しいドメインエキスパートの貴重な時間を浪

ユビキタス言語と日本語

数ヶ月前から社内でDDD勉強会を実施していて、最近「ユビキタス言語(Ubiquitous Language)」まで来たんだけど、ここでやっぱり「日本語を使ったら1つの言語、モデルになるのか？」という疑問が出てきた。JavaEE勉強会でも同様の意見が（確かhirataraさんから）出てきていたものの、残りの部分に答えが書いてある可能性もあったので、その時点では「まぁ、用語の一覧みたいなのを作ってなんとかすればいいんじゃないの？」と流したものの、あらためて同じ問題に直面してみると、なかなかやっかいな問題だ。先に進む前に、この時点での自分なりの結論を書いておく。 DDDの世界観まずは、DDDにおけるユビキタス言語やモデルの扱いについて簡単にまとめておく。 # 断るまでもないと思うけど、もちろん個人的な理解。ユビキタス言語はドメインモデルに基づく言語であり、ドメイン専門家と開発者の双方が作り、双方が使う。これら2つは一体となっており、片方が変更されればもう一方も変更される。ユビキタス言語が構成する世界−−言い換えれば、言語によって制限された物の見方−−がモデルであり、モデルは第一義的には概念上の存在である。わかりやすく言い換えると、モデルのマスターは頭の中に存在している、ってこと。これを文章やダイヤグラム、コードで表現することもできるけど、そうして表現されたものはすべてモデルの死体のようなもので、作った瞬間から古くなっていく。モデルが頭の中にしかないのであればユビキタス言語も同様で、会話の中にあらわれるものこそが第一義的な「ユビキタス言語」になる。僕たちはソフトウェアを開発したいので、モデルが頭の中にしかないってのはあまりうれしくない。最低でも（モデル表現としての）コードは必要になってくるけど、DDDではモデルを複数作らないのが原則だ。となると、コードの構造は頭の中のモデルを投影したものになり、コードはユビキタス言語で表現されることになる。 DDDの世界観は、こんな感じ。で、問題は何よ日本で開発する場合、顧客と開発者の会話はふつう日本語で行われる。よって、ユビキタス言語は日本語として構築されることになる。一方、プログラミング言語は通常英語（というよりは英数字）がベースだ。日本語プログラミング言語も存在しているが、少なくとも業務システムではほとんど使われていな

Nintendo DSで自作コードを動かすための環境の概要

PSPに比べて、Nintendo DSで自作コードを動かす環境を作るのは結構難しい。しかし、DSでiPodできるソフトやリモートデスクトップのようにPCを遠隔操作するソフトなど、魅力的なソフトが結構あるので、本気で環境そろえたい気持ちになってきた。 Nintendo DSで自作コード（homebrew）を動かすための環境については、 DSLinux というLinuxをDSに移植するプロジェクトの Wiki によくまとまっている。英語だけど。で、ざっと調べてみた結果…おおまかに言って、以下の2つの方法で自作プログラムを起動しているようだ。・DSのファームウェアを書き換えて、（正規品かどうかのチェックをスキップすることで）自作プログラムを動かすもの・自作プログラムを動かすためのアダプタプログラムを、正規のDSソフトとしてDS本体に認識させ、アダプタプログラムが自作コードを起動するもの 1.の手段の代表的なものが、FlashMeと呼ばれるもの。 DS（のファームウェア）はソフトの起動時にRSA署名をチェックすることでプログラムが正当なものかどうかをチェックしているようで、任天堂に承認されていないプログラムはこのチェックではじかれてしまう。そこで、DSのファームウェア自体を書き換えることで、このチェックをスキップしてしまおうというアイデアが1.になる。一度DSのファームウェアを書き換えてしまえば、元のデバイスは二度と必要なくなるので、誰かに借りることができるならお手軽にできるよう。 2.の手段の代表的なものは、PassMeシリーズやNoPassと呼ばれるもの。これは、DSソフトのスロットに正当なRSA署名を持ったプログラムを差してDSにはまっとうなソフトが起動すると思わせ、そのソフト経由で自作プログラムを起動するというアイデアで、チェックをスルーするためのアダプタのような働きを持つデバイスを利用する。このため、このアプローチでは自作プログラム格納用のデバイスを別途用意する必要があり、アダプタ製品によってプログラム格納用デバイスの種類が異なる。アダプタ自身が別のカード（CFとかSDとか）を差すスロットを持っている場合には、ここに直接差す。持っていない場合には、GBAスロットにカードを差すこととなる。ただしこのケースでは、直接GBAスロットに差すことのできるカード

Powered by Blogger

投稿テスト

コメント