エピローグ (p.500) †
要約 †
- 最先端のプロジェクトに参画したり、興味深い発想やツールを試すのはいいものだが、プロジェクトにとっての本当の成功とは、長い期間に渡って利用されることだ。
- 私が参画してきた５つのプロジェクトについて語ろうと思う。どれもdomain-driven designを試みたものだ。うまくいったものばかりでなく、何年も成長を続けたものもあれば、頭打ちになってしまったものも、すぐにダメになってしまったものもある。
- 第１章で解説したPCBデザインソフトはβ版は評判が良かったが、マーケティングに失敗して撤収となった。β版は今でも何人かのPCBエンジニアに利用されており、大きな仕様変更が入るまでは使われるだろう。
- 第９章で解説したローンのソフトは、ブレイクスルーの後３年間成長を続けた。そこでプロジェクトは独立した別企業となり、その騒動でマネージャと有力な開発者が何人かプロジェクトを抜けた。後を継いだチームは少し違うデザイン思想を持っていたが、ドメインレイヤは保持され、独立から７年経っても機能追加が続いている。
- 多くのプロジェクトにおける興味深いソフトウェアは短い期間で開発されるので、deep modelの威力を活かしきれない。もっと多くを望まない訳ではないが、実際にはそういったソフトも長い間継続して価値を提供している。
- あるプロジェクトではABSTRACT COREを用いてsupple designを作り出した。引き継ぎではメンバーが総入れ替えとなったため、設計が変わってしまうことを懸念したが、徹底したテストスイートとドキュメントが役に立った。１年後に話を聞いてみると、UBIQUITOUS LANGUAGEが生き続けていた。
- さらに１年後、デザインに根本的な変更を迫る要件が現れたが、そこではdeeper modelへのブレイクスルーが生じていた。
- その話をしてくれた時、彼らは私が気分を害するのではないかと思ったようだが、そんなことはない。deep modelは新しい洞察へと導く明確なビジョンを与え、supple designは変化を容易にする。ソフトウェアは変化するものなのだ。
- この本のあちこちで登場する輸送システムの例はとある国際輸送会社のプロジェクトに根差していた。プロジェクトリーダはdomain-drivenなアプローチには共感を示したが、カルチャーがついてこなかった。それでもCORE DOMAINに対するdeep modelを作り上げたし、UBIQUITOUS LANGUAGEも見える形になっていた。
- しかし、イテレーティブな開発が許されなかったので、問題が発覚するのは非常に遅れた。ある時、データベースのパフォーマンス問題が発生した。MODEL-DRIVEN-DESIGNが実装上の問題からフィードバックを受けて変更されることは自然なことだが、このケースでは遅すぎたため、コードを細工しなければならず、モデルとの結びつきが弱まってしまった。他にも最初のリリースであったスケーリングの限界などに対応が入ったりもした。それでも、実装とドメインモデリングとのループは閉じることがなかった。
- 分かれていたチームの中では、優れたソフトウェアを作ったチームもあれば、UBIQUITOUS LANGUAGEに従っていたのにモデルが単なるデータ構造になってしまったチームも合った。こういう各チームの成果物がバラバラな時にはCONTEXT MAPが役に立ったかもしれない。それでも、UBIQUITOUS LANGUAGEの中のCOREモデルが最終的な統合の助けになった。
- スコープが狭まりはしたが、このプロジェクトはいくつかのレガシーを置き換えることはできた。何年か経った今、これ自体がレガシーとなってしまったが、今でも24時間稼働している。優秀なチームの影響は少しずつ広まったが、結局は時間切れとなった。MODEL-DRIVEN-DESIGNがプロジェクトのカルチャーに吸収されることはなく、新しく始まった開発には間接的な影響しか与えていない。新しい開発者たちはこのレガシーに対してCONFIRMしているのだ。
- この輸送会社のように大仰なゴールを設定するのではなく、スコープを限定して小さいアプリケーションを作ろうという考え方は確かにある。しかし、統合されたmodel-drivenのシステムは小さいアプリケーションにはなし得ない価値を提供できる。domain-driven designはdeep modelとsupple designによって大きなシステムが成長を続けることを可能にする。
- 最後に在庫管理システムを開発している会社であるEvantを挙げる。ここには既に強力なデザイン文化があった。XPの申し子と呼んでいる人もいるが、注目すべきは極めてdomain-drivenな点だ。順調だったプロジェクトも2001年の"dot com crash"の際には危機に陥ったが、2002年になって10本の指に入るリテーラーから話が舞い込んだ。これはスケールアップのためにデザインの変更を要するものだったが、最後のチャンスと言えた。
- このために４人の開発者チームが結成された。全員が優れた技術とドメインの知識を備えており、うち１人はスケールアップの専門家だった。彼らの獅子奮迅の働きによって夏にはソフトウェアが完成し、それによって他の企業からも声がかかった。
- XPのカルチャーと同じく、domain-driven designのカルチャーも変遷を越えて活性化された。私が抜けた後２年経って、遥かに多機能になっている。Evant社内ではこれに続けという動きになっており、この流れは今でも続いている。
この本で書かれたテクニックを全て使いつくすプロジェクトなどはない。そうであっても、domain-driven designに共感するプロジェクトはどれも、何らかの形でそれと分かるようになる。特徴を見極めることが、対象となるドメインを理解し、そこで理解したものをソフトウェアに組み込む上で最も重要な事となる。それ以外のもの全てはその前提から流れ出す。チームメンバはプロジェクトにおける言葉の使い方に意識を向けてそれを洗練させる。メンバがドメインモデルの質に満足することはなかなかない。それはドメインについて学び続けているからだ。洗練しつづけることがチャンスであり、整合しないモデルはリスクなのだ。デザインの技術が大切な事と見なされる。ドメインモデルを明確に反映したプロダクション品質のソフトウェアを開発するのは容易ではない。つまづくこともあるが、自らの原則を保ちながら、立ち上がって前へと進んでいくのだ。
担当者のつぶやき †
- 「言っている事は分かるけれども、実現は難しいよね」というスタンスでここまで来たと思うんですが、実際Evansが苦労していないかというとそういう訳でもなさそうですね。ただ、これを支えるのは結局「人」で、どう育てるのか（あるいはどうそこまで自分を高めるのか）が一番難しい気がします。
- 誰かが言ってましたっけね。「"最後は人"じゃない、"最初から人"なんだ」と。
みんなの突っ込み †
- やろうと思ってたらアサインが。。ありがとうございます！ -- 角田?
- どもです^^って、4:38！？ -- 和智?
