関西DDD.java スタートアップスペシャル【大阪 9/5】 #kandddj
本日は、こちらの勉強会に参加してきました。
登壇者の増田(@masuda220)さんが、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を題材として、その全てを案内してくださいました:kansaiddd.connpass.com
はじめに~自分の立ち位置~
まず、自分はこれから読む、これからドメイン駆動設計(DDD)を学ぶところです。まだ理解している訳ではありません。次に、普段の業務では、現時点では、基本的に 「OO(オブジェクト指向) + ウォーターフォール」で開発しています。
その立場で感じたことを、セッション中のメモを基に、書いてみようと思います。
公開情報
※セッション資料:ドメイン駆動設計」の複雑さに立ち向かう
特に印象に残ったこと
- ドメインモデル
- OO(オブジェクト指向) + XP(エクストリーム・プログラミング)= ドメイン駆動? どちらも「変更に適応しやすい」ことを目指している。
種類 | 例 | 最終生成物 | 手法 |
予測型 | ウォーターフォール | 事前に定義、厳密に定義、固定 | 分析、設計、製造 |
反復、漸進型 | RUP | それなりに定義。反復ごとに精緻化。 | 方向付、推敲、作成、移行 |
適応型 | XP | ざっくりと定義。積極的に日々更新 | 日、週、春夏秋冬(人間の生活リズム) |
- ドメインモデルで駆動する。画面仕様や機能仕様やデータモデルで駆動するのではない。そうすることにより、今後膨らましていくことができることがメリットである。例えば、モデルを先に用意して、新しい「画面」の必要性に気付く、等。
- モデルとコードを一致させる。一致させることはそもそも難しいこと(一つの理由:脳内で自動的に翻訳してしまい勝ちだから)なので、一致させ続ける継続的な取り組みが必要。
- 基礎を身に付けた後は、より厳しい現場でも、それを実践できるように。
- 「言葉」が大事
- カタカナ言葉は誤解しやすい。ぎこちなくても日本語にしよう。
- 「ドキュメント」をレビューするより、「言葉」の方がフィードバックが早い。違和感などがあれば、その場で指摘できる。
- 「言葉」を「チーム」内で「統合」し続けよう。
- 暗黙的な概念をどう掘り起こすか?
- 言葉に耳を傾ける
- ぎこちなさを精査する
- 矛盾について熟考する
- 文献を読む
- 何度でも挑戦する
- 大事なのは、「言葉」、「コード」、「チーム」。
- コードを変更する人間が戦略を理解し、実行に移すことがもっとも効果的。たとえ非公式の場しか設けられないとしても。
- 最後に:エクストリームプログラミング より引用:
- どんな「状況」でも改善できる
- どんなときでも「あなた」から改善を始められる
- どんなときでも「今日」から改善を始められる
感想
- 全体像を見せてくださったので、とても読み進めやすくなったと感じます。
- 特に、「モデル駆動」という発想が新鮮でした。
- 普段、どちらかと言えば、画面仕様や機能仕様、データモデルなどの「外部」から出発して「内部」に向かうような、いわば「トップダウン」(というイメージを抱いています)の設計を行うことが多いのですが、そこには、特に、「必要以上の機能の発散」を防ぎやすい、というメリットがあると感じています。
- 一方、現時点で理解している「モデル駆動」とは、ちょうど逆方向、「ボトムアップ」の設計手法というイメージで捉えています。モデルからある種の「拡がり」が起こることを、むしろメリットと考えるという印象です。
- これら2つの違いは、開発プロセスの性質の違いが根底にあるように感じます:
- すると、現在の現場にDDDを導入していくためには、開発プロセスも含めて、改良が必要と考えますが、「変化」を受け入れるというスタンスは、現実に即しており、腑に落ちる感覚があります。
- さらには、自分自身も含めて「コードを変更する人間」が「戦略」を理解し実行に移すことがもっとも効果的であることから、開発プロセスの改良にとどまらず、さまざまな関係者との、適切な言葉、すなわち、適切なコミュニケーション能力が必要であると感じます。
- 今回のお話をベースに、本を読み進めるとともに、DDDを勉強したいと思います。
おわりに
おかげさまで、とても有意義な時間を過ごすことができました。これもひとえに、増田(@masuda220)さん、スタッフの皆様、会場を提供してくださった楽天株式会社様、参加者の皆様のおかげであると感謝しております。本当にありがとうございました。