読者です 読者をやめる 読者になる 読者になる

LIFE LITERACY

エンジニアの生活の質を向上させる方法について整理中

エンジニア必読の書「実践ドメイン駆動設計(IDDD本)」

スポンサード リンク

実践ドメイン駆動設計

実践ドメイン駆動設計

僕は、数ヶ月前に、2ヶ月程度かけて実践ドメイン駆動設計を読み終えて、現在その効果を少なからず感じているところである。 実践ドメイン駆動設計の素晴らしさについては、さまざまな人が語っているので、僕の個人的な状況も踏まえて良かった点・参考になった点について述べる。

関連記事 lifeliteracy.hatenablog.com

読みやすいし参考情報も豊富

IDDD本の目的は、エリック・エヴァンスが確立した理論を実際の設計に応用するであり、 DDDのテクニックをSaasOvationという擬似プロジェクトで実践しながら、系統立てて説明していく。

サンプルコードが豊富であり、「カウボーイの声」がちょっとした息抜きになるので、固い技術書ほど読むのが苦痛にはならない。

しかし、600ページ弱とそれなりの分量があり、また扱っているテーマがそもそも難しいため、途中で挫折する人も多いだろう。 そんな人は、まずはネットで情報収集をして、ある程度DDDについて予備知識をつけてから読み始めると良い。

僕は読み終わってから知ったのだが、例えば、 http://www.slideshare.net/AtsuoAoki/iddd17 などはわかりやすくまとめられていて参考になる。

DDDのおかげで他チームとも仲よくなった

システムを開発する上で、厄介な課題の一つに他システムといかに連携するかというのがある。 こちらが、上流のシステムであれば、下流のシステムに迷惑をかけないように、全力を尽くすだけであり、 プレッシャーはあるものの責任感を持って仕事をしようという気持ちになる。

しかし、こちらが下流のシステムであり、さらに上流システム開発者が協力的でないときは、 技術的な課題ではなく、政治的・人間的な課題がチーム稼働を奪うことになる。

僕がいたプロジェクトでは、残念なことに下流チームが「順応者」とならざるを得ないことが多かった。 以下は、順応者の定義の抜粋(p89)である。

順応者: 二つの開発チームに上流/下流関係があるにも関わらず、上流に下流チームの要求に応える動機がない場合、下流チームはどうすることもできない。人の役に立ちたいという思いから上流開発者は約束するかもしれないが、それが守られるとは思えない。

上流開発者も当然良い人ばかりで、なんとか下流チームのために頑張ろうとはしてくれるが、彼らのチーム事情(例えば、上司が下流チームのために稼働を割くことを許可してくれない)により、 結果的に、下流チームが「順応者」となってしまうことはよくあることである。

ただ、実践ドメイン駆動設計を読んだことにより、「パートナーシップ」、「顧客/供給者の開発」や「順応者」について順序立てて説明できるようになり、 今まで非協力的だった相手とも、一定の協力関係を結べるようになってきた。

ソースコードが格段に綺麗になった

実践ドメイン駆動設計により、正しい設計手法を身につけることにより、コードそのものも綺麗になった。 おそらく、設計が上手になったことと、顧客の要望を適切にドメインモデルに反映することができるようになったのも大きいと思う。

名言が心に響いた

IDDDの各章のはじめに、偉人たちが残した名言・格言が記載されている。 その中でも特に僕の心に響いたのは、第3章(p83)の、

何をやろうとしても、あなたは間違っていると批判する者がいる。その批判が正しいと思わせる多くの困難がたちはだかる。計画を描き、最後まで実行するには、勇気がいる。 - Ralph Waldo Emerson

ちょうどこれを読んでいたときに、僕は個人的に大きな決断をして実践し始めたところだった。しかし、さまざまな困難に遭遇し心が折れ気味だったのだが、この格言を読んでなんとか乗り切ることができた。 これを読んで以来、僕は他人の決断をより尊重するようになった。

まとめ

とにかく素晴らしい本なので、業務システムを開発している人たちは一度読んでみると良いだろう。 通読した後に、実際に自分のプロジェクトで実践しながら読み返していくのがおすすめの実践法である。

余裕があれば、本家が書いた書籍を読むのも良いだろう。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)