ソフトウェアの設計・開発で、OO:Object Oriented は、根本的な考え方の変化(パラダイムシフト)だと思う。 ソフトウェア開発の世界では、"Object Oriented" は、誰もが聞いたことがある言葉だと思うが、意味や使い方が、人によって、状況によって、ばらばらな、かなり不可思議な言葉でもある。 OOP:オブジェクト指向プログラミング オブジェクト指向言語を使ったプログラミングの総称？ もし、Java , C#, PHP5 などをオブジェクト指向言語と呼べるなら、世の中には、オブジェクト指向プログラマがたくさんいるわけだ。 実感とはだいぶ違う。 分析や設計の考え方が　オブジェクト指向じゃないのに、言語だけ、オブジェクト指向（風？）でもそれは、ＯＯＰとは言えないですよね。 OOAD:オブジェクト指向分析設計 UML でクラス図とか描くこと？ オブジェクト指向言語の話といっしょ

採用業務の状態管理の仕組みをモデリングしている。 状態管理を、イベントソーシングスタイルで、やるための、大まかなクラス構成を絵にしてみた。 それぞれのクラスの役割をできるだけ、単純明快にすることを、重視した。 関心ごとの分離（ SoC : Separation of Concerns )原則、 単一責任原則 ( SRP : Single Responsibility Principa ) をこころがけたつもり。 メッセージング ／ Web アプリケーション 上半分は、メッセージングのフレームワーク Mule ESB での実装をモデル化したもの。 下半分は、（今までやってきた） Web アプリケーションの MVC モデル、サービス層／ドメイン層／インフラ層のレイヤ構造を整理したもの。 Mule ESB のサービス部品と、Web アプリで使う Service クラスとは、完全に一致していない。

業務の情報の扱い方の基本スタイルとして、 * state ソーシング * event ソーシング がある。 state が先か、event が先か、という正反対のスタイル。 現在の「状態」を中心にしたスタイル。 state オンリー 一番、単純なパターン。 いわゆる「上書き」モード。 メモリ上のオブジェクトを、 setter とか　update メソッドで、最新の状態を保持する。 更新前の状態は、どこにも残っていない。 テーブルであれば、update 文で、最新の状態に上書きしていくパターン。 もっとも単純だし、これで要件が満たせるなら、これで必要十分。 情報源は、「上書き」された最新の　state だけ。　これが、state ソーシング のもっとも、単純な state オンリー パターン。 state - audit log パターン state を変更した時に、記録を残すパターン。 a

今のプロジェクト「ドメインモデル駆動開発」に、こだわって、やっている。 ドメインモデル駆動開発（DMDD:Domain Model Driven Development) は、モデリングや設計よりも、実際のコードの書き方が、主要な関心事。 やり方 具体的、かつ、簡単。 基本のアイデアは、Eclipse プロジェクトを、レイヤごとに、別々に作成すること。 （１）まず、ドメイン層のプロジェクトを作って、ドメインのクラス群を作る （２）次に、データベースを定義する （３）次に、データアクセス層の　プロジェクトを別に作って、ドメイン層プロジェクトを参照する。 O-R マッピング ( SQL Map ) の仕組みを使って、ドメイン層で宣言した、 Repository インタフェースを、実装する。 （４）次に、サービス層のプロジェクトを、さらに別に作る。 このプロジェクトも、ドメイン層プロジェクトを参

システムをデッサン（素描）する時の、基本ダイアグラムは、 ■振る舞い系 コンテキスト図（概要のユースケースモデル） アクティビティ図（業務プロセスとプロセス間のやり取り） ■構造系 概念モデル（概要のクラス図、パッケージ図） 配置モデル などがある。 振る舞い系のレイアウト 振る舞い系は、基本的に、時間の経過とともに、振る舞いが変化することを表現している。 だから、レイアウトの基本は、時間の流れ順。 ・上から下へ ・左から右へ が普通のレイアウト。 ユースケースモデルであれば、アクタの登場順、ユースケースの発生順が基本のレイアウト。 アクティビティ図も同じですね。 システム全体のデッサンよりも詳細な設計用のダイアグラムだけど、ロバストネス図、ステートマシン図、シーケンス図なども、振る舞い系のダイアグラム。 基本のレイアウトは、時間順に、上から下、左から右。 これ、あたりまえのようで、描いて

Domain-Driven Design(DDD)１７章に、ドメイン駆動設計を、やるための、６つのチェック項目が載っている。 □　Context Map を描いてみる：　Ｑ．　ちゃんと描ける？ □　プロジェクトチームの「言語」：　Ｑ．　コードもドメインの用語が中心？ □　重要事項の理解度：　Ｑ．　Core Domain を発見した？　Domain Vision Statement ある？ □　プロジェクトの技術基盤：　Ｑ．　「モデル駆動設計(MDD)」向き？　or MDD の障害 ? □　メンバーのスキル：　Ｑ．　「必要」なスキルセットを持っている？ □　知的興味：　Ｑ．　メンバーは、ドメインを知ることに興味を持っている？ このチェックリストで、自分たちの５年前（出発点）、現在、今後の見通し（？）を、書いてみる。 Context Map をちゃんと描ける？ ■５年前 言葉すら知らなかった。

去年の１１月くらいに DDD を読み直しながら、自分の頭を整理するために、ブログで、DDD ネタをいろいろ書いてきた。 ５００ページ、１７章を、ようやく読み終わった。お疲れさまでした、という感じだな。 何度も読み返してきたけど、ちゃんと通読したのは、今回がはじめて。 今までの読み方が甘かったのが、とてもよくわかった。 まあ、新鮮な発見がいっぱいあって、何か、新しい本を読んだような気分でもある。 自分たちが実践していること、できていること、できていないことも含めて振りかえってみて、改めて、Domain-Driven Design について、思ったことを、書き留めておきたい。 モデル駆動設計 DDD 前と後で、自分にとって、一番の発想の転換は「モデル駆動設計 ( Model-Driven Design )」に目覚めたことだった。 この本に出会うまでは、自分は、徹底的にコード命。エディタだけが、

ソフトウェアの分析・設計で、 ◎責任駆動設計 ( RDD : Responsibility-Driven Design ) ◎レイヤ構造 ( Layered Architecture ) の二つは、ソフトウェアをわかりやすく扱いやすくするための、基本かつ強力なテクニック。 Domain-Driven Design (DDD)の、16章「構造設計」で、この二つを駆使した、Responsibility Layers パターンが登場する。 責任駆動設計 オブジェクトごとに、単純で、明確な役割を持たせるように、設計すること。 たとえば、（日時ではなく）日付だけを 扱う BusinessDate クラスや、DateRange クラス。 日付や期間を扱う時は、こいつらに全部まかせる。 時・分・秒とかは、別の TimePoint クラスとか、Interval クラスとか、Duration クラスとかが、

エバンスは、セミナーで、１５章の「コアドメイン」（問題の核心）は、Domain-Design Driven(DDD)本の、もっと前に書くべきだった。２章とか、３章に書くべきだった、というようなことをしゃべっていますね。 ◎ユビキタス言語　（いつでも、どこでも、業務の言葉） ◎モデル駆動設計　（絵や文で、コミュニケーション） ◎Hands-on モデラ 　(実際に、コードを書くモデラー） という、ドメイン駆動設計の基本コンセプトのひとつとして「コアドメイン」を力説すべきだったと。 コアドメインの効用 Core Domain を見つけ出し、そこに、モデリング、設計・実装のエネルギーを集中する。 その他の部分は、Core Domain との関係（近い？遠い？）、Core Domain にとっての重要性、という視点で整理する。 Core Domain との関係が弱く、重要でもない部分は、できるだけ

ドメイン層で、if 文や、for 文がぐちゃっと、書かれた部分を見つけたら、たぶん、Cohesive Mechanizms パターンの出番。 ドメインモデルの中で、if 文や　for 文がごちゃごちゃ書かれている部分を、うまく括りだして、パッケージやクラスにすると、ドメインモデルの見通しがよくなるよ、というパターン。 ツリー構造、グラフ構造 for 文がぐちゃっと書かれている場合、モデルとしては、ツリー構造や、グラフ（node と edge ) 構造で、情報を扱っていることが多い。 Domain-Driven Design(DDD) では、例として、 ・組織階層 ・輸送経路 を扱う業務を取り上げている。 組織（ツリー構造) 組織の「指揮・命令系統」「報告先」とか「責任・権限」とかが、ツリー構造になっている。 LDAP などは、こういう構造を扱えるツール。 業務アプリだと、所属部門とか、上司

ドメイン（問題領域）のモデリングを始めると、「よくでてくる、部分的な問題」がいろいろ見えてくる。 こういう所は、できるだけ、手間をかけずにサクッと解決したい。 エヴァンスは、Domain-Driven Design(DDD) で、Generic Subdomain の設計・実装のやり方を、４つ上げている。 Ａ．オフ・ザ・シェルフ ( 買う、または、オープンソースソフトの利用) Ｂ．公開されている設計や分析パターンを参考にする Ｃ．実装を外注（コアの技術者以外にやらせる） Ｄ．社内で部品ライブラリとして整備 作る場合（外注でも内製でも）、設計は、 ■（オフザシェルフの）設計を参考にする ■公開された設計や分析パターンを参考にする のどちらかになる。（よくある問題を、白紙から設計する、という選択肢はない） どの手段を選んでも、メリット、デメリットがあって、選択は難しい。 いや、私たちの場合、G

あるアプリケーションのドメイン（問題領域）は、コアと、それ以外の部分がある。 Core Domain には、もっとも優秀なメンバーを優先的にアサインする。 じゃあ、それ以外の部分をどうするか？ Generic Subdomains パターンが、その答えの一つ（すべてではない）。 タイムゾーンの例 Domain-Driven Design(DDD) で、Generic Subdomains の例としてエヴァンスが書いているのが、タイムゾーン付きの日時の扱い。 ２つのプロジェクトを対比させて説明している。 国際輸送 「国際輸送」を扱うプロジェクトでは、貨物の「現在」位置や、到着予定を、出発地、到着地の「現地時間」で扱う必要がある。 しかも、輸送の途中で「日付変更線」を西から東に超えたり、東から西に超える。 ドメインモデリングの過程で、この「日時」の扱いが重要な課題として明確になった。 重要では

ソフトウェアの中心課題を、簡潔な文章で表現する Domain Vision Statement は、役に立つ。 でも、チームのメンバーの理解が共通かどうかは、ちと怪しい。 同じ文章を読んでいるのに、結構、違うことを考えているもんですよね。 そこで、Domain Vision Statement パターンよりも、もっと、具体的に、Core Domain を共通理解にするテクニック。 ・３−７ページ程度のコアの解説ドキュメント (Distillation Document) ・既存モデルにマーカーで、色づけ ( Flagged Core ) Core Domain の解説ドキュメント (The Distillation Document) 数行の、Domain Vision Statement では、あいまいさが残るので、もうちょっと、具体的に解説しよう、ということ。 ボリューム的には、３ペー

Domain-Driven Design(DDD)を読み直している。 Domain Vision Statement パターン (415ページ)にたどり着いた。 これ、ドメイン駆動設計の基本中の基本のやり方だと思った。 現場で、まだ、実践できていないけど、これから、Domain Vision Statement パターンを徹底してやってみようと思う。 Core Domain の文章表現 Domain Vision Statement は、いま造っているソフトウェアの基本価値を、文章で表現したもの。 エヴァンスは、１ページ程度といっているけど、もっと短くてもいいと思う。 （最初は、長めで、だんだんシェイプアップしていく？） 大切な点： ◎業務の言葉で、業務の関心事を書くこと ◎今回のソフトウェアのこだわりポイントを書く ◎技術者以外のレビューとフィードバック ◎なんども、書き直す 業務の言葉

Domain-Driven Design (DDD) １５章に出てくる、Core Domain の抽出テクニックは、６つ。 ・Domain Vision Statetment ・Highlighted Core ・Generic Subdomains ・Cohesive Mechanisms ・Segregated Core ・Abstract Core どういう順番でやることも可能。 でも、設計・実装へのインパクトには、だいぶ違いがある。 Domain Vision Statement 「重要な関心事」を短くまとめた文章。 ・簡単に、作成、修正できる。 ・チーム内で、基本イメージやキーワードを共有できる。 ・設計・実装には、影響はない。 Highlighted Core 既存のモデル（クラス図やパッケージ図）で、重要な所を、赤でマーキング、というようなイメージ。重要なクラスと関連だけを抜

開発プロジェクトの初期には、技術者は、その問題領域（ドメイン）の知識が少なく、理解も浅い。たぶん、あまり興味もない。 Core Domain が問題の核心で、Core Domain のモデリングと設計・実装が、ソフトウェアの価値、プロジェクトの成果を大きく左右する。 Core Domain の開発は誰が、どうやるべきか。 ・パターン（ベストプラクティス）は？ ・アンチパターンは？ ベストプラクティス もっとも優秀でやる気のあるメンバーを集めて、そのチームに、Core Domain のモデリング、設計・実装をやる。 ソフトウェアの価値、プロジェクトの成果を左右する核心部分だから、当然ですよね。 現実には、技術的には優秀だし、経験も豊富だけど、ドメインを理解したり、ソフトウェアで表現することに、興味を持たない技術者が大勢いること。 私の場合は、私が部門の責任者なので、 ・ドメイン層の設計・実装

むちゃくちゃな一週間だったなあ。 けっこう大規模な新システム構想が持ち上がったので、 ・クライアントと打ち合わせ ・提案活動 ・メンバーの緊急招集 ・たたき台づくり ... で忙殺された一週間。 ほかの仕事がなくなったわけではないので、もろ追加の仕事。 まあ、ここに書く時間は、削ったわけだが、ちょっといやな感じがしている。 確かに、Domain-Driven Design(DDD)をじっくり読み返して、考えをまとめなおして、文にしてみる、という時間は、とれなかった。 でも、タスクに追われているだけでは、どうも、道を誤りそうな、恐怖感を感じはじめた。 構想が大きいだけに、無理やり、「じっくり考える」時間をとるべきなんじゃないかと。 ここに書くことができていれば「考える時間をとっている」という、チェックポイントにしようかと思いなおしたところ。 まあ、それを、休日にやっているは、問題なんだけど。

ドメインモデルのどこかに「問題の核心」がある。 問題領域の中の「核心」の問題領域が、Core Domain。 Domain の中の Domain ですね。 Core Domain を発見し、そこに切り込んでいくのは、もっとも優秀なメンバーたちにやらせる。 開発パワーを、問題領域の全体に、広く、薄く分散させるのは、失敗パターン。 ほんとうに役に立つソフトウェアを造るために、「問題の核心」を正しく捕らえ、そこに集中して、設計・実装し、リファクタリングして、洗練させていくこと。 Core Domain の特定と、設計・実装が、プロジェクト全体の成果を大きく左右する。 ・Core Domain とは何か？ ・どうやって発見するか？ ・どうやって表現するか？ ・Core 以外の扱い方は？ ．．． これが、 Domain-Driven Design(DDD)　15章 "Distillation"(抽出

抽象化 (abstraction) は、設計の基本スキルですね。 とはいっても「抽象化とは何か？」とか「どうやって抽象化するか？」を、簡単に説明するのは難しい。 私の場合「抽象化」という言葉を理解してから、設計を覚えたわけではない。 ソフトウェア開発の現場で、失敗しながら覚えてきた「コツ」みたいなものが「抽象化」と呼べるかな？という程度の感じ。 超自己流「抽象化論」．．． 抽象化の結果 抽象化は「手段」なので、何か結果が残ります。 「あるもの」を抽象化すると「別のもの」が出てくる。 そして、抽象化した「結果」は、元の「あるもの」に比べ、 ・小さい ・少ない ・短い ．．． という特徴がある。 簡単でしょう？ 「小さくする」「少なくする」「短くする」ことが「抽象化」なんです。 大きくなる、多くなる、長くなるのは、抽象化とは、正反対の方向。 これは、具象化。「具だくさん」にすること。 「お吸い

ドメイン駆動設計の１４章は、規模の大きいアプリケーションシステムのモデリングと設計の「基本用語」を提示している。 これらの言葉を、共通の言語とすることで、プロジェクトの関係者が、アプリケーションの全体像を、話合うことができる。 ・現状はどうなっているか？ ・これから、どうしていこうか？ ．．． プリミティブ ほかの用語を使うための、基本中の基本の用語。 ・Bounded Context ・Continuous Integration(CI) ・Context Map ・開発チーム 使用例： ・ひとつの Bounded Context は、ひとつ開発チームが担当する ・Bounded Context は、CI で、整合性を確保する ・複数の Bounded Context 間の関係を、Context Map で描く。 連携パターン 連携パターンは、 ・Separate Ways ・Confo