ドメイン駆動設計 序文

序文だけで9ページあって、結構読むのもたいへん。
(形容詞とかが難しい言葉が多いのが DDD の難点ですね)

この本の前提(価値観)

1.ソフトウェアプロジェクトの最も重要な関心ごとは、ドメインそのもの、そして、ドメインのロジック
2.複雑なドメインの設計(実装)は、モデルを基にする (いきなりコードで書きはじめない)

ドメイン駆動設計 ( DDD: Domain-Driven Design ) は、

・考え方
・優先順位のつけ方

である。

設計と開発プロセス

「設計」本と、「プロセス」本は、いっしょになっていることはないし、お互いに参照すること自体少ない。(別世界、別の関心ごと)

でも、本来は、不可分。しごくもっともな主張です。

まあ、そうはいっても DDD は 「設計」本なので、プロセスを取り上げる箇所は少ない。

唯一、この序文の xxii ページが、具体的にプロセスについても語っている箇所。

まあ、簡単に言えば「アジャイル開発プロセス」との相性がいいよ、といっている。

まあ、Eric Evans の人脈が、オブジェクト指向+アジャイル ( Smalltalk 人脈?)なんだから、あたりまえですけどね。

小さな反復を繰り返し、コミュニケーションとフィードバックを大切に、継続的に発展させていく、というのが、XP や、その他のアジャイル方法論でも共通の価値観ですね。 DDD も、その価値観・やり方が基本。


ドメイン駆動設計の目指すもの

ドメイン駆動設計(DDD) は何をめざしているのか?

対象のドメインがビジネス(業務)であれば、ドメイン駆動とは、ビジネス駆動、業務駆動ですね。
DDD の最初の三つの章を「業務駆動」で考えてみると...

第1章 知識の習得

業務の知識こそ、業務アプリの核心

第2章 コミュニケーションと言語

開発チームは、業務の言葉で話をする。
設計もコードも、業務の言葉を使う。

第3章 モデルとコードの一致

業務モデル(模型)をそのまま動くソフトウェアにする。


DDD は、この三つを実践するためのテクニック、ノウハウ、具体例、というわけです。

出発点は、業務の理解と知識。
ゴールは、その知識を、動くソフトウェアにすること。

「ドメイン」を、ソフトウェアのレイヤ構造とか実装パターンとして考えると、DDD はぴんとこない。

「ドメイン」とは、ソフトウェアの外側の世界。
ソフトウェアを使う人たちが行動する領域。

その領域に注目して知識を獲得するのが、DDD 実践の第一歩。

ビジネスアプリケーションであれば、そのソフトウェアを使う、ビジネスの現場が「ドメイン」。

ドメイン駆動とは、ビジネスの現場から出発し、ビジネスの要望や期待を原動力にソフトウェア開発を進めることなんですね。

今年のチャレンジテーマ

今年は、新しい仕事にもチャレンジしたいと思い、動き始めてみました。
少しずつ、方向感と動きがでてきた感じ。

去年は、国際B2Bの会社と、転職サイトの会社をかけもちで、チーフアーキテクトと若手の育成がおもな仕事。ちょびっと、自分でコード書いたりもしていた。( Hands-on アーキテクトなんで )

今年も2社の仕事は続いている。特に、B2Bのほうは、追加の案件がいくつか控えていて、それなりに忙しそう。

この2つの会社の仕事をやりながら、仲間たちと、いろいろな成功や失敗を繰り返してきた。また、書籍やオープンソースコミュニティを漁って、外部の技術情報の勉強もそれなりにやってきた。

こういう中から見えてきたこと、手に入れたノウハウを、もうちょっと整理して、他の人も使いやすい形で提供してみよう、というのが今年の目標。

ビジネスとしては未知数だけど、現場で役に立つ実用的なサービスを、リーズナブルな価格で提供できればと思っています。

テーマは、大きく四つ考えている。

・ドメインモデリング
・アジャイル開発プロセス
・ワークベンチ(開発の場)
・アプリケーションプラットフォーム(実行環境)

ドメインモデリング

これが駆動エンジンですね。
役にたつソフトウェア、価値のあるソフトウェアを作るには、ドメインの理解が基本中の基本。

DDD(ドメイン駆動設計)のアプローチとテクニック、REAビジネスパターンとアナリシスパターン。
これを元ネタに現場で、いろいろ試行錯誤してきた内容を、できれば、現場でいっしょに開発しながらトランスファーできたらよいな、と思っている。

どれも最初な難解だったけど、現場で試行錯誤しながら、だいぶ消化できてきた感じがするんですよね。

アジャイル開発プロセス

まず、要件定義から開発までは、神崎さんの「RDRA(リレーションシップ駆動要件定義)」と ICONIX の組み合わせに手ごたえを感じている。

実践的だし、実用一点張りの感じがとても気にっている。(形式的な方法論ではない)

現場で若手に分析や設計の仕事を教える時に、いろいろ苦労してきた。この2つの方法論に出会ってから、驚くほど、分析・設計の仕事を教えやすくなった。

アジャイルといえばXPが有名だけど、現場で教えるには、ちょっとむずかしい。(私には、無理)

プロセスの後半は、配置と運用。

配置については、 One Click Deploy を目指して、試行錯誤中。
運用も、自動運転フレームワークみたいなものを試行錯誤中。

これも、現場のプロジェクトに入り込んで、いろいろノウハウや失敗談をトランスファーできればよいな、と思っている。

ワークベンチ

方法論の実践の場として、やはり、開発環境は、重要。

特に、アジャイルの方法論を実践するには、

・リポジトリ(情報のストック)とコミュニケーション(情報のフロー)
・テストのセットアップ・実行・クリーンアップの自動化

など、ツールをうまい使い方が成功のポイント。

こういう作業環境って、以外と立ち上げて活用するのがたいへんなことが多かったので、そこらへんのノウハウを外部に提供して、活用してもらえなかな、と考えている。

アプリケーションプラットフォーム

ひとつは、Webアプリケーションのプラットフォーム。
これは、Spring, iBatis, velocity で、かなりパターン化できてきた。
( PoEAA の実践編という感じ)

もうひとつは、システム間の連携のプラットフォーム。

RESTful 系というか、 XML over HTTP の軽量なやり方がてごたえ十分。
あとは、製品だけど、Asteria Warp Light パイプライン もすぐれものです。

これも、わかってしまえば簡単なことも、立ち上げのときは、かなりたいへんだった。
ここらへんのノウハウも、提供してみたい。

ちょっとした活動拠点も確保できたし、今年はいろいろチャレンジの年にしたいと思っています。


calendar
1234567
891011121314
15161718192021
22232425262728
<< February 2009 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM