平々毎々 (Hey hey, My my)

rock and roll can never die.

月別アーカイブ: 4月 2008

MSに染まらない.NET開発 : 書籍「ドメイン駆動」

読み終わったので。

ドメイン駆動

ドメイン駆動

  • 作者: Jimmy Nilsson, 尾島良司, 株式会社ロングテール長尾高弘
  • 出版社/メーカー: 翔泳社
  • 発売日: 2008/03/20
  • メディア: 大型本

マインドマップは「続きを読む」で……邦題は「ドメイン駆動」と言い切っちゃってて、Evansの”Domain-Driven Design”と区別がつきにくいが、原題は”Applying Domain-Driven Design and Patterns: With Examples in C# and .NET”ということで、.NETにおけるドメイン駆動設計の進め方を本にしたもの。
厚さはそれなりなんだけど、思ったより読みづらくて、読み進めながらイライライライラ。読み終わってから気づいたんだけど、この本は読者に対してこれから進んでいく方向というか道筋みたいなものをほとんど提示しない。とりあえず行き当たりばったりで話を進めていくのだ。そして問題にぶつかったところでいくつかの選択肢を提示し、1つを選んでまた進むというスタイルで設計を洗練させていく。まあそれがYAGNIということなのかもしれないし、そのような進め方を読者に見せたくてわざとやっているのかもしれない。でも、ドメインモデルを洗練させていくところに図がほとんどなくて、提示されるソースコードも断片しかないんだぜ?
ただ、あらかじめどこに進もうとしているのかを分かっていれば、別段難しい話はでてこないし、実践的な内容なので、参考になるだろう。特に4, 5, 6, 7章と11章は面白かった。ポイントは「他の何者にも依存しない、純粋なドメインモデル」だ。最終ゴールが見えていて、各章での進む先が分かっていれば、別にC#や,NETのことを知らなくても楽しめると思う。

最後に、この本を読もうかどうしようか迷っている人のために、各章の簡単なまとめを書いてみた。各章のもっと細かい内容についても説明(省略されました。続きを読むにはわっふるわっふると書き込んでください)
thumbnail

  • hideADDDP
    • hide第 I 部 背景
      • hide第1章 尊重すべき価値
        • leaf先取りとYAGNI、アーキテクチャ先行とTDDのバランスが重要。
        • leafDDD+TDD+リファクタリング。RDBMSを使うならData Mapper。
        • leafCIツールも使おう。
        • leaf運用に必要な機能も忘れずに。
      • hide第2章 パターン入門
        • leafパターンは重要だけど万能じゃないよ。
        • leafGoF, POSA, PoEAA, DDDを紹介するよ。
        • leafパターンを使わない場合と使った場合の両方のサンプルコード。
      • hide第3章 TDDとリファクタリング
        • leafTDDの作業の流れをデモ。
        • leafモックやスタブに置き換えるデモ。
        • leafリファクタリングのデモ。
    • hide第 II 部 DDDの応用
      • hide第4章 新しいデフォルトアーキテクチャ
        • leafレイヤ分割の方針:ドメイン層が他に依存しないようにする。
        • leaf発注処理をサンプルにする。
        • leafUMLでスケッチしながら要件の理解を深め、アーキテクチャの選択をする。
        • leafここで考えた初期ドメインモデルをたたき台にするよ。
      • hide第5章 DDDの手法で前進する
        • leafTDDでドメインモデルを改良していく。
        • leaf設計を変えるときはテストコードを変えることもいとわない。
        • leafプロパティとかインスタンス化とかリポジトリからの取得とか一部のビジネスロジックとか。
      • hide第6章 インフラのための準備
        • leafPOJOとかPOCOとか、まとめてPI (Persistence Ignorance : 永続知らズ) と呼ぶよ。
        • leafPI原理主義。永続化インフラに依存するのはアノテーションですら嫌だ。
        • leafドメインモデル内のリポジトリは、IWorkspaceを実装するデータアクセスクラスを呼び出すことにする。
        • leafUnit Of Workパターンで行こう。
        • leafテストプログラムを修正。
        • leafQuery Objectも使いたい。
      • hide第7章 ルールを機能させる
        • leafビジネスルールについて詳しくは本を読んでね。
        • leafルールをチェックするインスタンスメソッドをたたき台にして改良していく。
        • leafドメインロジックのルールを実装してみる。
        • leaf永続化のためのルールもインフラに依存しないように実装してみる。
    • hide第 III 部 PoEAAの応用
      • hide第8章 永続記憶のためのインフラ
        • leafドメインモデルは極力インフラに依存しないようにする。
        • leafRDBMSを使うのが現実解。
        • leaf気の利いたSQLとか、強力なクエリとか、同時実行制御とかもできて欲しい。
        • leafO/Rマッパで楽したい。
        • leafスタイルや機能でインフラを分類してみる。
        • leafPoEAAのパターンでもインフラを分類できる。
      • hide第9章 NHibernateを導入する
        • leafHibernateの.NET実装。コーディングサンプルも紹介するよ。
        • leaf前章で挙げた要件はおおむね満たしている。
        • leaf前章で挙げた分類に従ってNHibernateの特徴を紹介するよ。
        • leafでは発注処理サンプルモデルに実際に組み込んでみよう。
    • hide第 IV 部 次は何か
      • hide第10章 これからの設計テクニック
        • leafいくつかの機能をまとめてパーティション分割して、それぞれ別のモデルを使うのもあり。
        • leafSOAについて。片方向非同期メッセージングは便利だよ。
        • leafDIについて。.NETでの実装例と、Service Locatorとの比較。
        • leafAOPについて。Spring.NETを用いた.NETでの実装例。
      • hide第11章 UIにフォーカス
        • leafUIは別レイヤにしよう。
        • leafMVCについて。分離してテストしやすくするサンプル。
        • leaf同様のことをASP.NET Webアプリケーションで試すサンプル。
        • leafプレゼンテーションモデルの検討とドメインモデルとの対応の付け方。
    • hide第 V 部 付録
      • hide付録 A 他のドメインモデルスタイル
        • leaf他の人が考えた、少し異なるアーキテクチャの方針をいくつか。
      • hide付録 B 論じたパターンのカタログ
        • leafGoF, POSA, PoEAA, PoEAA2, DDD, CoreJ2EE, 他にもいくつか。
広告

あなたのエディタで.NET開発

ハッカー気質の人にしてみれば自分の使い慣れたエディタで開発したいわけで、Visual Studioみたいに汎用性もないくせにやたらとデカくて重いIDEを強制させられるのは悪夢以外の何者でもない。
……と、いうことなのではないか。

いや、何が言いたいかというと、.NETのつまみ食いをしようと思った時にVSが障壁になってしまって、結果として敬遠されている面もあるのかなと。

もちろん、Visual Studioは使わなくたって開発できる。MSの技術カンファレンスやWebCastを見てても分かるが、MSの中の人でもたまにEmacsを使ってデモをしている人もいる。
# ITゼネコンな仕事でチーム開発をしている立場としては、Visual Studio縛りというのは(しょぼい独自フレームワークとか独自ツールとかを押し付けることを考えれば)かなりマシな方だと思うのだけど、それはまた別の話。

ってことで、たとえばVSを使わず、もっと言うとmsbulldも使わず、素のcscを使ったり、あえてmakeとかantとかから呼び出したりするサンプルとか、たとえば「連載:好きなエディタでSilverlight」みたいな企画はどうか。

MSも動き出しているんだね。

Perfumeと中二病 (Young, Alive, in Love)

「Duft Punkカコイイ! Perfumeパクんな!」
……中二病
「Duft Punkメジャーすぎ! Perfume興味ない」
……高二病
「Perfumeと中田ヤスタカはクール」
……大二病
「のっちかわいいよのっち」
……オッサン

こうですか!?わかりません!

そろそろTable Moduleについてひとこと言っておくか (overflow)

Table Moduleを語るにはDomain Modelのことも語らざるを得ないわけで、そんな頃にドメイン駆動が出たから買って読んでおり、まあ無駄に長い本で読むのに苦労し、くやしいからドメイン駆動の感想みたいなのもブログのネタにしようと準備していて、そしたらTable Moduleの方はすっかり手が止まってしまっている訳で。
先にドメイン駆動の方を片付けてしまう予定。

クライマックス刑事

ネタバレする気はないけど、一言感想だけ書いておく。

面白かったよ。でもね、もともとVシネマだった事を忘れてはいけないと思うんだ。

日立デザイン本部

本日、仕事で赤坂の日立デザイン本部を見学してきました。

「画面設計ソリューション」というのを持ってるということだったので話を聞きに行ったのですが、
ソフトウェア製品とかツールというのではなく、要件定義工程で提供するサービスの名称でした。

日立のデザイン本部は家電デザインから始まり、昨年で50周年を迎えた組織なのですが、
1985年からはGUI、1994からはWebも対象としているとのことです。

事例としては、

などがあります。

説明を受けた内容はものすごく真っ当でした。
ユーザを理解し、具体的なペルソナを想定してシナリオを作り、
プロトタイピングとユーザー評価を繰り返し実施し、
画面設計の標準を策定し、それを元に全画面設計を行う、
まさに教科書通りの進め方。
日立デザイン本部には黒須教授がいると言えば分かる人もいるでしょうか。

オフィスに併設されていた「ユーザビリティ・ラボ」も見ました。
本当にマジックミラーで仕切られているんだ!と変な所で興奮しました。

説明の中で心に残った点を列挙します。

  • デザイン本部は150人ほどだが、日立グループの中で考えると小規模。
  • デザイン本部は業務横断組織だが、その中でも分野ごとの担当がある。
    • プロダクト(家電、公共機器、産業機器など)
    • コミュニケーション(情報機器、ソフトウェアなど)
    • ヒューマン・インタラクション(新規デバイス研究など)
    • ユーザー・エクスペリエンス(ユーザビリティ評価など)
    • サービス・イノベーション(新しいビジネスやサービスの考案)
  • お客様にユーザビリティ(利用品質)の価値を理解してもらうのはやはり大変。経営層に働きかけて、業務改革の一環として理解してもらうのがよい。
  • ノウハウをドキュメントなどに落とし込む(形式知化する)ことも大事だが、組織としての暗黙知をメンバー全員で共有することも重要と考える。
  • ファシリテーション能力が重要。
  • 高レベルなサービスを提供できなければならないので、全員参加のトレーニングコースなどを定期的に行っている。

日立デザイン本部の50年に及ぶ歴史は、この本にまとめられています。


ソーシャルイノベーションデザイン―日立デザインの挑戦

ソーシャルイノベーションデザイン―日立デザインの挑戦

  • 作者: 紺野登
  • 出版社/メーカー: 日本経済新聞出版社
  • 発売日: 2007/12
  • メディア: 単行本

PS
日立ユニバーサルデザインのブログもありました。

C#で関数型: Unfold

関数型言語にはUnfoldという関数が用意されていることが多い。Schemeだとこんな感じ。

(unfold p f g seed tail-gen) ==
   (if (p seed)
       (tail-gen seed)
       (cons (f seed)
             (unfold p f g (g seed))))

これをC#に直訳する。ただし、tail-genは無視する(optionalなので)。

public static IEnumerable<U> Unfold<T, U>
(
  Predicate<T> p,
  Func<T, U> f,
  Func<T, T> g,
  T seed
)
{
  if (p(seed))
    return Enumerable.Empty<U>();
  else
    return Cons
    (
      f(seed),
      Unfold(p, f, g, g(seed))
    );
}
 
public static IEnumerable<T> Cons<T>
(
  T car,
  IEnumerable<T> cdr
)
{
  yield return car;
  foreach (T element in cdr)
    yield return element;
}

これって、結局こういうこと。(そして、C#には末尾最適化がないのだから、必ずこう書くべきだ。)

public static IEnumerable<U> Unfold<T, U>
(
   Predicate<T> p,
   Func<T, U> f,
   Func<T, T> g,
   T seed
)
{
   for (T i = seed; !p(i); i = g(i))
      yield return f(i);
}

だったら、パラメータの順番を変えたほうが、Unfoldを呼び出すときにIntelliSenseが効いてうれしい。

public static IEnumerable<U> Unfold<T, U>
(
   T initial,
   Predicate<T> until,
   Func<T, T> next,
   Func<T, U> convert
)
{
   for (T i = initial; !until(i); i = next(i))
      yield return convert(i);
}

C#にわざわざUnfoldを用意する必然性はあるのだろうか。自分でも考えてみる。
そうだな、匿名メソッドやラムダ式ではyieldが使えないけど、それで困るようなシチュエーションならFoldとかUnfoldとかその類のメソッドがあると便利。
でもより重要なのは、きっとDLinqやPLinq(んー、でもUnfoldを並列処理するのは難しいか)みたいな世界に簡単に対応できるというポテンシャルなんだろう。そういう意味では、今現在での意味は薄いのか。

404 Table Module ないわー (そろそろTable Moduleについてひとこと言っておくか) (2)

前回のエントリにひがやすをさんからコメントをもらった。

DataSetは

org.seasar.extension.dataset

で一応実装されてます。

ひがさん、ありがとうございます。
しかしながら、JavaでDataSetを実装するエントリで時間を稼ぐという目論見はあっけなく崩れ去ってしまった。

さて、Seaser2のDataSet実装を使って話を進めようと思うが、今回のネタのためにSeaser2を使うのはちょっと重装備すぎるように思ったので、DataSet実装だけ切り出してみた。ファイルはここに置いた
元ファイルに加えた変更点は:

  • ログ機能は削除
  • リソースからメッセージを取得する機能も削除
  • それに伴い、SRuntimeExceptionとSSQLExceptionを使わないように修正
  • Beanを使ってDataTableをセットアップする機能を削除

といったところ。

戦わないプログラマ@はてな

そろそろTable Moduleについてひとこと言っておくか(1)

まずひとこと。このシリーズではJavaを使うよ!

ビジネスロジック部分のパターンとしてMartin Fowlerの”Patterns of Enterprise Application Architecture”(以下、PoEAA)で挙げられているのが、”Transaction Script“、”Table Module“、そして”Domain Model“。
ビジネスロジックについてはこの分類に沿って語られることが多いのだが、ほとんどの場合Table Moduleはいらない子扱いされている
「んー?Table Module? なんか.NETのやりかたでしょ?うちらはJavaで(Spring|Seasar2)でDomain Modelだから関係ないしー」
まあ、確かにDomain ModelでやれてるんならTable Moduleはシカトしてもいいけど、でもTransaction Scriptで頑張ってるんなら、そしてDomain Modelがハードル高いと感じているのなら、Table Moduleにも目を向けたほうがいいんじゃないの?

とはいっても、Javaでの実装の仕方が分からん。
分からんけど実装してみよう。というのがこのシリーズだ。

まずは、.NETのTable Moduleで使われている(とされている) DataSetをJavaで使えるようにしてみる。
dataset UML