2012-06-26 要求開発アライアンス６月定例会

munch_bot @swata_bot

原理主義はワークしない（上手く働かない）。現実解を探り続けるのが重要。なので、程ほどのところで収めるようにする。

munch_bot @swata_bot

ユーザを巻き込めないのはやはり致命的。

munch_bot @swata_bot

みんな（答え・未来は）わからない。コンサルは見通しを出さなければならない。話し合ってるよりも、お薦めの仮説を出さないと話は進まない。

munch_bot @swata_bot

以上、山岸さんのお話でした。

munch_bot @swata_bot

引き続き杉山さんのお話。「DDD&アジャイルの実践的アプローチ」

munch_bot @swata_bot

１．DDDとは。２．ドメインモデルパターンについて。３．DDDのエッセンス。４．ドメインモデルパターン適用の戦略。５．DDD＆Agile。６．InfoQと参考資料の紹介。 の流れ。

munch_bot @swata_bot

Scrumで実践しました。

munch_bot @swata_bot

１．DDDについて。ここで言っている「ドメイン」とは、「知識」「影響」または「活動領域」の事。

munch_bot @swata_bot

一言にはなってないんですが（笑）、定義は以上です。

munch_bot @swata_bot

ドメインモデルパターンについての説明。ファウラーが提唱したドメインロジックパターンの一つである（詳細はエンタープライズアプリケーションアーキテクチャパターン 参照）

munch_bot @swata_bot

ドメインモデルパターンとトランザクションスクリプトパターンの比較。後者はWF型開発に最適なので、主流。前者はOO型なので、日本では少ないがアメリカでは主流。

munch_bot @swata_bot

正しい、ドメインモデルパターンはDRYになっていて、変更に強い。

munch_bot @swata_bot

DDDのエッセンス（ドメインの隔離とパターン適用）について。「ドメイン」は一部に過ぎないが、だから重要ではないと言うわけではない。

munch_bot @swata_bot

どうやってドメインを構築する事ができるか？ ドメインをソフトウェアシステムの他の機能から切り離す必要がある。ドメインを、モデルとしてパターンを適用する必要がある。

munch_bot @swata_bot

星空を見上げて、方角を定め、星の位置のパターンに沿って星座を見つけ出すようなイメージ。これがドメインを探し出す感覚に似ている。

munch_bot @swata_bot

DDDでの構成要素の説明。１．ドメインの隔離（レイヤ化アーキテクチャ）。２．パターンの適用（ドメインオブジェクトのモデル、ライフサイクル）

munch_bot @swata_bot

レイヤ化アーキテクチャについて。4つ存在。１．UI（Strutsとか）。２．アプリケーション（ドメインへの引き渡し用ファサード。ビジネスロジック書いたらダメ）。

munch_bot @swata_bot

３．ドメイン（ココが主役。ビジネスの概念を表現している）。４．インフラストラクチャ（DBへのデータの永続化とか、上位レイヤを支援するための層）。また以上4つは１．⇒４．へ依存するようにしなければならない（依存性の方向）

munch_bot @swata_bot

DDDでは、ドメイン層を定義する事が必須。また、各層は疎結合に保つ事。

munch_bot @swata_bot

ユースケースについての説明。

munch_bot @swata_bot

あ、時間が無いですね(^^;;

munch_bot @swata_bot

ケーススタディの説明。モデル図での説明なので、省略。

munch_bot @swata_bot

１．アプリケーションのサービスを定義する。２．クラスの分類（エンティティとバリューオブジェクトの区別重要。エンティティはJavaのエンティティBeanとは別。バリューオブジェクトは不変オブジェクトとなる）

munch_bot @swata_bot

全てのオブジェクトを（個別に認識して）追跡すると性能の最適化は不可能になるので、なるべくバリューオブジェクトにする。

munch_bot @swata_bot

続いて関連の設計について。UMLで言うところの誘導方向性。について、整理する。