開発プロジェクトの初期には、技術者は、その問題領域（ドメイン）の知識が少なく、理解も浅い。たぶん、あまり興味もない。
Core Domain が問題の核心で、Core Domain のモデリングと設計・実装が、ソフトウェアの価値、プロジェクトの成果を大きく左右する。
Core Domain の開発は誰が、どうやるべきか。
・パターン（ベストプラクティス）は？
・アンチパターンは？
もっとも優秀でやる気のあるメンバーを集めて、そのチームに、Core Domain のモデリング、設計・実装をやる。
ソフトウェアの価値、プロジェクトの成果を左右する核心部分だから、当然ですよね。
現実には、技術的には優秀だし、経験も豊富だけど、ドメインを理解したり、ソフトウェアで表現することに、興味を持たない技術者が大勢いること。
私の場合は、私が部門の責任者なので、
・ドメイン層の設計・実装が、最大の成果
・ドメイン層を作るのが優秀な技術者
という価値観を徹底（強制？）しているので、比較的、話しは簡単。
RDRA(リレーションシップ駆動要件定義）と、ICONIX(ユースケース駆動開発実践ガイド）のやり方で、ドメインをモデリングさせる。
ドメインのモデルのレビュー・改良に一番時間をかける。
その中で、いちばんモデリングの意欲とスキルの高いメンバーを、 Core Domain に割り当てる。
技術者の評価基準は、「インフラ層のコードを理解したり自力で書ける」ことは軽視。
「ドメインを理解し、モデルに描ける」ことを重視して、評価、指導している。
どちらかというと、技術的にとんがったメンバーが少ないチームなので、わりと、素直に「ドメインのモデル」重視、というカルチャーになってきた。
腕自慢のメンバーと仕事をする時には、私が責任者である限り「ドメインの理解」「ドメインへの興味」が、第一優先事項ということを、明言し、徹底している。
もちろん、力のある技術者からは、反発や、技術力の評価が不当に低い、という不満はたくさんでてきます。
一般論とか、個人の価値観とかまで立ち入る気はない。それは、個人の自由。
ただ、私は、ソフトウェア開発プロジェクトの成功の鍵は「ドメイン駆動設計」であり、Core Domain の設計・実装であることに、信念を持っている。私が責任者である限り、この価値観は徹底することにしている。
技術者たちが、業務の言葉を積極的に理解し、それをソフトウェアで実現しようとしている、という雰囲気が、まわりに伝われば、プロジェクトがうまく回りだすことを、何度も経験している。
もちろん、良いソフトウェアを作るには、インフラ層も、ＵＩ層も、良いソフトウェアにする必要がある。ただし、それは必要条件で、十分条件からは、ほど遠い。
ドメイン層の充実・洗練、中でも、 Core Domain の充実と洗練が、価値のあるソフトウェアの十分条件。
だから、Core Domain には、もっともやる気があって優秀なメンバーを割り当てる。
Core Domain に優秀なメンバーを割り当てないのは、アンチパターン。失敗パターンですね。
アンチパターンとしては、
・初心者任せ
・外部コンサルタントの支援
・既存ソフトの外部調達
がある。
腕自慢の技術者は、彼らが興味を持つ、インフラ層や、UI コントロール、自作のフレームワークやライブラリの開発、などのテクニカルなタスクに割り当てる。
実際の業務の機能は、初心者クラスのメンバーに、「この通りやれば動くから」といって、丸投げ。
データベースの項目と、画面の項目をせっせとマッピングするだけの仕事なんて、ほんとの技術者のやる仕事じゃない．．．
こういうプロジェクトが世間では多いのかなあ？
良い悪いという議論をする気はないけど、「ドメイン駆動設計」的でないことは確かですね。
「ドメイン層」こそ、ソフトウェアの価値の源泉だと思うんだけどなあ。
プロジェクトの初期に、アナリスト、モデリングのプロ（？）、その業務に強いベテランＳＥとかを、かりだすパターン。
そのプロジェクトにべったりというわけにいかないので、プロジェクトの初期に短期だけ。
彼らに Core Domain をやらせれば、それなりに、良い仕事をしてくれる。
プロジェクトに専任予定のメンバーたちより、「上流」で力の差があることが、はっきりしている。
でも、問題は、彼らが抜けた後。
ドメインモデルは、継続的に、地道に改良・発展させていくもの。
ましてや、Core Domain こそ、いちばん、エネルギーと時間をかけて、継続的に発展させていく。
短期の高級（高給）メンバーが、やった仕事は、出発点としてレベルが高いかもしれないけど、それを、設計・実装し、育てていくのは、元々のプロジェクトメンバー。
彼らは、それらしいドメインモデルがあっても、実コードではないので、理解ができず、白紙から、コードレベルで、格闘することになる。
高い金を払って、モデルを作っても、誰もそれをありがたいとは思っていない。
これも、典型的な失敗パターンですね。
もし、コアのプロジェクトメンバーが、ドメイン層に真剣に取り組みたいと思っていて、彼らを、Jump Start させるために、ブースター役として、外部の優秀なスタッフに手伝ってもらう、というのはありだと思う。
でも、主役は、あくまでも、プロジェクトのメンバーじゃないといけない。
Core Domain の外部調達はありえない。
すくなくとも、開発プロジェクトで、「ここが核心」という部分は、自分たちで開発すべき場所。
そうじゃなかったら、そもそも、その開発プロジェクトは実施されていないはず。
■ 他の目的や背景に基づいて作られたソフトウェア
■ どういう環境でも、汎用的に使えるように、一般化を重視し、カストマイズ機能をヘビーに作りこんであるソフトウェア
こういうソフトウェアは、今のプロジェクトの問題の核心 ( Core Domain ) を解決するソリューションとしては、ぴったりくるはずがない。
なんでも自作、という主張をするつもりはありません。
でも、「Core Domain」だけは、自作し、継続的に育てる以外に、良いやり方はない。
Core Domain のモデリング、設計・実装に、優秀なメンバーを投入することが、役に立つソフトウェアを造り出す、ベストプラクティスなんです。
優秀なメンバーを、Core Domain に、できるだけ長期間、割当て、継続的な洗練を地道に続け、Core Domain の設計・実装を発展させていく。
他にいろいろしわ寄せが来るけど、そっちは、別の手段で、なんとか、やりくりする。
プロジェクトの人員配置、時間配分、外部資源の調達は、すべて、Core Domain を中心に、判断をしていく。
Core Domain が問題の核心で、Core Domain のモデリングと設計・実装が、ソフトウェアの価値、プロジェクトの成果を大きく左右する。
Core Domain の開発は誰が、どうやるべきか。
・パターン（ベストプラクティス）は？
・アンチパターンは？
ベストプラクティス
もっとも優秀でやる気のあるメンバーを集めて、そのチームに、Core Domain のモデリング、設計・実装をやる。
ソフトウェアの価値、プロジェクトの成果を左右する核心部分だから、当然ですよね。
現実には、技術的には優秀だし、経験も豊富だけど、ドメインを理解したり、ソフトウェアで表現することに、興味を持たない技術者が大勢いること。
私の場合は、私が部門の責任者なので、
・ドメイン層の設計・実装が、最大の成果
・ドメイン層を作るのが優秀な技術者
という価値観を徹底（強制？）しているので、比較的、話しは簡単。
RDRA(リレーションシップ駆動要件定義）と、ICONIX(ユースケース駆動開発実践ガイド）のやり方で、ドメインをモデリングさせる。
ドメインのモデルのレビュー・改良に一番時間をかける。
その中で、いちばんモデリングの意欲とスキルの高いメンバーを、 Core Domain に割り当てる。
技術者の評価基準は、「インフラ層のコードを理解したり自力で書ける」ことは軽視。
「ドメインを理解し、モデルに描ける」ことを重視して、評価、指導している。
どちらかというと、技術的にとんがったメンバーが少ないチームなので、わりと、素直に「ドメインのモデル」重視、というカルチャーになってきた。
腕自慢のメンバーと仕事をする時には、私が責任者である限り「ドメインの理解」「ドメインへの興味」が、第一優先事項ということを、明言し、徹底している。
もちろん、力のある技術者からは、反発や、技術力の評価が不当に低い、という不満はたくさんでてきます。
一般論とか、個人の価値観とかまで立ち入る気はない。それは、個人の自由。
ただ、私は、ソフトウェア開発プロジェクトの成功の鍵は「ドメイン駆動設計」であり、Core Domain の設計・実装であることに、信念を持っている。私が責任者である限り、この価値観は徹底することにしている。
技術者たちが、業務の言葉を積極的に理解し、それをソフトウェアで実現しようとしている、という雰囲気が、まわりに伝われば、プロジェクトがうまく回りだすことを、何度も経験している。
もちろん、良いソフトウェアを作るには、インフラ層も、ＵＩ層も、良いソフトウェアにする必要がある。ただし、それは必要条件で、十分条件からは、ほど遠い。
ドメイン層の充実・洗練、中でも、 Core Domain の充実と洗練が、価値のあるソフトウェアの十分条件。
だから、Core Domain には、もっともやる気があって優秀なメンバーを割り当てる。
アンチパターン
Core Domain に優秀なメンバーを割り当てないのは、アンチパターン。失敗パターンですね。
アンチパターンとしては、
・初心者任せ
・外部コンサルタントの支援
・既存ソフトの外部調達
がある。
初心者まかせ
腕自慢の技術者は、彼らが興味を持つ、インフラ層や、UI コントロール、自作のフレームワークやライブラリの開発、などのテクニカルなタスクに割り当てる。
実際の業務の機能は、初心者クラスのメンバーに、「この通りやれば動くから」といって、丸投げ。
データベースの項目と、画面の項目をせっせとマッピングするだけの仕事なんて、ほんとの技術者のやる仕事じゃない．．．
こういうプロジェクトが世間では多いのかなあ？
良い悪いという議論をする気はないけど、「ドメイン駆動設計」的でないことは確かですね。
「ドメイン層」こそ、ソフトウェアの価値の源泉だと思うんだけどなあ。
外部コンサルタントの支援
プロジェクトの初期に、アナリスト、モデリングのプロ（？）、その業務に強いベテランＳＥとかを、かりだすパターン。
そのプロジェクトにべったりというわけにいかないので、プロジェクトの初期に短期だけ。
彼らに Core Domain をやらせれば、それなりに、良い仕事をしてくれる。
プロジェクトに専任予定のメンバーたちより、「上流」で力の差があることが、はっきりしている。
でも、問題は、彼らが抜けた後。
ドメインモデルは、継続的に、地道に改良・発展させていくもの。
ましてや、Core Domain こそ、いちばん、エネルギーと時間をかけて、継続的に発展させていく。
短期の高級（高給）メンバーが、やった仕事は、出発点としてレベルが高いかもしれないけど、それを、設計・実装し、育てていくのは、元々のプロジェクトメンバー。
彼らは、それらしいドメインモデルがあっても、実コードではないので、理解ができず、白紙から、コードレベルで、格闘することになる。
高い金を払って、モデルを作っても、誰もそれをありがたいとは思っていない。
これも、典型的な失敗パターンですね。
もし、コアのプロジェクトメンバーが、ドメイン層に真剣に取り組みたいと思っていて、彼らを、Jump Start させるために、ブースター役として、外部の優秀なスタッフに手伝ってもらう、というのはありだと思う。
でも、主役は、あくまでも、プロジェクトのメンバーじゃないといけない。
既存ソフトを外部調達
Core Domain の外部調達はありえない。
すくなくとも、開発プロジェクトで、「ここが核心」という部分は、自分たちで開発すべき場所。
そうじゃなかったら、そもそも、その開発プロジェクトは実施されていないはず。
■ 他の目的や背景に基づいて作られたソフトウェア
■ どういう環境でも、汎用的に使えるように、一般化を重視し、カストマイズ機能をヘビーに作りこんであるソフトウェア
こういうソフトウェアは、今のプロジェクトの問題の核心 ( Core Domain ) を解決するソリューションとしては、ぴったりくるはずがない。
なんでも自作、という主張をするつもりはありません。
でも、「Core Domain」だけは、自作し、継続的に育てる以外に、良いやり方はない。
Core Domain 開発 ベスト・プラクティス
Core Domain のモデリング、設計・実装に、優秀なメンバーを投入することが、役に立つソフトウェアを造り出す、ベストプラクティスなんです。
優秀なメンバーを、Core Domain に、できるだけ長期間、割当て、継続的な洗練を地道に続け、Core Domain の設計・実装を発展させていく。
他にいろいろしわ寄せが来るけど、そっちは、別の手段で、なんとか、やりくりする。
プロジェクトの人員配置、時間配分、外部資源の調達は、すべて、Core Domain を中心に、判断をしていく。
