関西DDD.java スタートアップスペシャル【大阪 9/5】 #kandddj

本日は、こちらの勉強会に参加してきました。
登壇者の増田(@masuda220)さんが、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を題材として、その全てを案内してくださいました：kansaiddd.connpass.com

はじめに～自分の立ち位置～

まず、自分はこれから読む、これからドメイン駆動設計(DDD)を学ぶところです。まだ理解している訳ではありません。次に、普段の業務では、現時点では、基本的に 「OO(オブジェクト指向) + ウォーターフォール」で開発しています。
その立場で感じたことを、セッション中のメモを基に、書いてみようと思います。

公開情報

※セッション資料：ドメイン駆動設計」の複雑さに立ち向かう

• はてなブックマーク - 関西DDD.java スタートアップスペシャル（大阪 9/5) - connpass
• 20150915 関西DDD.java スタートアップスペシャル - Togetterまとめ
• 関西DDD.java スタートアップスペシャル行ってきたのでメモ公開 - 日々の御伽噺
• Domain Driven Design で Evans の言う「設計」って何？ #kandddj - Mitsuyuki.Shiiba

特に印象に残ったこと

• ドメインモデル
  • ドメインモデルとは、
    • ソフトウェアを「利用」する人たちの「活動」と「関心事」の本質を簡潔に表したものである。
    • ソフトウェアそのものやソフトウェアを作る側の「活動」や「関心事」ではない。
    • 「技術」の話ではなく「業務」の話である。
  • ドメインには、膨大な背景「知識」がある。
  • ドメインモデルを作る際は
    • 特に重要なところを要約する
    • あまり重要でないところをそぎおとす
  • 「モデルを改良する」という方向で「リファクタリング」を継続的に行う。「技術的な」観点での「リファクタリング」ではない。

• OO(オブジェクト指向) + XP(エクストリーム・プログラミング）＝ ドメイン駆動？　どちらも「変更に適応しやすい」ことを目指している。
  • XPでおすすめの本：Wabi-Sabi わびさびを読み解く for Artists, Designers, Poets & Philosophers
  • 開発プロセスの種類

種類	例	最終生成物	手法
予測型	ウォーターフォール	事前に定義、厳密に定義、固定	分析、設計、製造
反復、漸進型	RUP	それなりに定義。反復ごとに精緻化。	方向付、推敲、作成、移行
適応型	XP	ざっくりと定義。積極的に日々更新	日、週、春夏秋冬（人間の生活リズム）

• ドメインモデルで駆動する。画面仕様や機能仕様やデータモデルで駆動するのではない。そうすることにより、今後膨らましていくことができることがメリットである。例えば、モデルを先に用意して、新しい「画面」の必要性に気付く、等。

• モデルとコードを一致させる。一致させることはそもそも難しいこと（一つの理由：脳内で自動的に翻訳してしまい勝ちだから）なので、一致させ続ける継続的な取り組みが必要。

• 基礎を身に付けた後は、より厳しい現場でも、それを実践できるように。

• 「言葉」が大事
  • カタカナ言葉は誤解しやすい。ぎこちなくても日本語にしよう。
  • 「ドキュメント」をレビューするより、「言葉」の方がフィードバックが早い。違和感などがあれば、その場で指摘できる。
  • 「言葉」を「チーム」内で「統合」し続けよう。
  • 暗黙的な概念をどう掘り起こすか？
    • 言葉に耳を傾ける
    • ぎこちなさを精査する
    • 矛盾について熟考する
    • 文献を読む
    • 何度でも挑戦する

• 大事なのは、「言葉」、「コード」、「チーム」。

• コードを変更する人間が戦略を理解し、実行に移すことがもっとも効果的。たとえ非公式の場しか設けられないとしても。

• 最後に：エクストリームプログラミング より引用：
  • どんな「状況」でも改善できる
  • どんなときでも「あなた」から改善を始められる
  • どんなときでも「今日」から改善を始められる

感想

• 全体像を見せてくださったので、とても読み進めやすくなったと感じます。
• 特に、「モデル駆動」という発想が新鮮でした。

• 普段、どちらかと言えば、画面仕様や機能仕様、データモデルなどの「外部」から出発して「内部」に向かうような、いわば「トップダウン」（というイメージを抱いています）の設計を行うことが多いのですが、そこには、特に、「必要以上の機能の発散」を防ぎやすい、というメリットがあると感じています。

• 一方、現時点で理解している「モデル駆動」とは、ちょうど逆方向、「ボトムアップ」の設計手法というイメージで捉えています。モデルからある種の「拡がり」が起こることを、むしろメリットと考えるという印象です。

• これら２つの違いは、開発プロセスの性質の違いが根底にあるように感じます：
  • 前者（普段の自分の開発）は、ウォーターフォールという「予測型」であり、最終生成物が「固定」である方向に向かう
  • 後者（モデル駆動）は、開発プロセスが「適応型」であり、変化を肯定している

• すると、現在の現場にDDDを導入していくためには、開発プロセスも含めて、改良が必要と考えますが、「変化」を受け入れるというスタンスは、現実に即しており、腑に落ちる感覚があります。

• さらには、自分自身も含めて「コードを変更する人間」が「戦略」を理解し実行に移すことがもっとも効果的であることから、開発プロセスの改良にとどまらず、さまざまな関係者との、適切な言葉、すなわち、適切なコミュニケーション能力が必要であると感じます。

• 今回のお話をベースに、本を読み進めるとともに、DDDを勉強したいと思います。

おわりに

おかげさまで、とても有意義な時間を過ごすことができました。これもひとえに、増田(@masuda220)さん、スタッフの皆様、会場を提供してくださった楽天株式会社様、参加者の皆様のおかげであると感謝しております。本当にありがとうございました。