関西DDD.java スタートアップスペシャル に 参加しました #kandddj

はじめに

関西では「DDD」に関する「勉強会・読書会」などが定期的に開催されていたのは知っていて、興味はあったのですが、実務でDDDを使う機会もなかったためか、自然と勉強する機会も失っていた今日この頃・・・。

今回のような「スタートアップ」的なものだったら自分でもいけるかなと思い、本を1冊も持っていない状態でしたが、ネットやtwitterで事前に情報を仕入れて思い切って参加してみました。

関西DDD.javaって何?

今回の勉強会の幹事である川上氏から、現場でDDDを使い続けて感じていることと、この勉強会を開催した経緯についてのお話しがありました。

既に実践されている川上氏でも「ドメインと出来上がるソフトウェアを一致させること」がいかに難しいかと言うことをおっしゃっていて、個人的にはDDDも(オブジェクト指向設計と同様に)奥深さがあるのだなと感じました。

また、関西とJavaのコンテキストを利用しつつ、DDDを中心とした様々な考え方を共有したいという思いから、

 関西+DDD+.java= 関西DDD.java

を開催するに至ったということで、既に色々やりたいことを発表されてました。次はどのテーマになるかはわからないのですが非常に楽しみです。

対象の本はこちら

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

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

 

 資料はこちら

それではレッツゴー

プレゼン資料を元に、私のメモと感じたことを書きたいと思います。長くなりそうなので、超絶暇な時の読み物としてダラダラ読んでいただけるとうれしいです。

また、冒頭にも触れてるとおり、私は「DDD」のいわゆる「超初心者」なので、記載内容に関して少しとらえ方が間違っていることもあると思います。そういう部分は「ここはこういう考え方が良いよ」とかのアドバイスをいただけると幸いです。

考え方と背景(まえがきと結論から)

まず、本題に入る前に、今回の登壇者である増田氏から、本の導入についてのお話がありました。本を読み進めて行く上で参考になる情報やDDDについての考え方のウォーミングアップ要素がいくつかありましたのでピックアップします。

  1. 本は読み直してみると「まえがき」と「結論」はすごくいいですよ
  2. パターン本というよりも「成功と失敗の経験や教訓」が書いてありますよ
    ・成長していく様子に着目して読むとすごく面白いよ
    ・1章・7章・8章・13章・15章・結論 が わかりやすい
  3. 前提知識は「オブジェクト指向+XP」 この2つは学ぶべし
  4. 「第2部」の内容だけでは不十分、DDDをやっても全く効果はない
    ・あくまでも基本スキル、3部・4部への繋ぎである
  5. 「変化に適応」する「技術」なんですよ
    ・変化:オブジェクト指向=変更容易性=独立性の高い部品
    ・適応:XP=適応型=日々変化
    ※ スライド「P.15」の表が参考になります。
  6. モデルとコードを最初から「作りきる」のではなく「成長」させるイメージ
    ・現時点のコードがどれくらいモデルと一致しているかがDDDの醍醐味
  7. 「言葉」に敏感に反応し「チーム」による「改良」を目指す
    ・「ドキュメント」よりも「言葉」が非常に大事
    ・「意見交換」の中で設計・モデリングをしていくことが大事
    ・「カタカナ言葉」は日本語で柔らかく具体的に説明できることを目標にしよう

私は「変化に適応する技術」と「ドキュメントよりも言葉」というところがすごく気になったところです。どちらも今の現場ではなかなか実践できていないことだったからです。

特に「言葉」というものを改めて考えてみて、自分自身が毎日交わす言葉が非常に雑多だなと感じることです。毎日チーム内で交わす言葉ですが、意識しているように見えていても、カタカナ用語に流されてみたり、辞書で開くような小難しい言葉を使ってみたりと反省する点が多くあるからです。

いやいや、毎日交わす言葉はきっちり使い分けているよ…っていう方はどれくらいいらっしゃるのか気になりますが、DDDに限らずこの「言葉」はこれから意識して使っていかなければと思いました。

第1部:ドメインモデルを機能させる

まずは各章に入る前にドメイン・モデルについてのポイントの説明がありました。

  • ドメインドメインでないことの区別はしっかりつけましょう
    例えば、画面仕様書とか機能一覧はドメインではありませんよ
  • アクティビティ図・業務フロー図などを使い重要な要素を発見する
  • モデリングとは、重要な関心事を文章で論理的につなげることができるか
    すなわち「利用する言葉を組み合わせて論理的に説明」することができるか
  • クラス図・パッケージ図を使い、未来のコードのイメージを膨らませる
  • ドメインが研ぎ澄まされていればコードも研ぎ澄まされていく

この後に、各章のお話しが始まりました。

第1章:知識をかみ砕く

変化と成長の様子を読み取ることがこの章のポイントでありますと。

ほとんど何もわかっていない状態からモデリングを行い、新しい言葉が増えてきて、モデリングしていくうちに、どんどん本質的な関心事をとらえながら要件定義(成長)していくストーリーを学べる章になっていますと。

第2章:コミュニケーションと言語の使い方

ここで出てくる「ユキビタス言語」ですがポイントは以下の通り

  • コードの複雑さを言葉で共有できるようにところを目指す
  • 他の言葉や表現の不一致に敏感になること(別の概念が潜んでいることがある)
  • ドメインモデルのサブセット的な存在ですよ
  • 1つ1つの「言葉の意味」を「的確」に捉えて使えるようにしていく

良いモデリングをするためには、きちんと声に出すことが重要ですと。上記にも書いた通り、表現の不一致には敏感になって、普段から会話などを通じて、お互いの情報を共有していくイメージ。もちろん毎日、継続的にね。

ドキュメントに落とすって考え方もいいんだけど、それに偏るのは良くないよねと。毎日鍛錬されている「言葉」でやりとりする方が反応も早いし、いいタイミングでいい指摘などもできるメリットを享受しやすいよねと。(ドキュメント絶対ダメという感じではなく、必要最低限のドキュメントでいいじゃないかというスタイルっぽかった)

第3章:モデルと実装を結びつける

モデルとは「要点を選び抜いた簡潔な表現」ではあるものの「でも簡単には見つからない」だから「言葉とコードを書くことだ(実験することだ)」ということですと。

UMLでお客様とやり取りできるかというテーマについては、それ単体だけでは厳しいという感じで、ラフスケッチで画面のナビゲートをする感じでクラス図を説明すればいけるそうです。(たしかに上に行けば行くほどわからない人多いもんね)

実践的モデラのところでは、コードを書く人がドメインの知識をかみ砕き、ユキビタス言語を作り上げていく(骨格を作り見せていく)ことが、より効果的なソフトウェア、早いソフトウェアの構築ができるよというお話しもいただきました。

第2部:モデル駆動設計の構成要素

でも実際、DDDを始めてみると、頭の中の理解とコードが違うことって多くあって、なかなか一致しないよと。それは、実装者があるときに「自分の都合のいいように翻訳=バイアスをかけちゃったり」しちゃうから。しかも後でなぜこうなったのか…と聞かれると説明ができなくなったりするものだから厄介ですねと。

だから、モデルとコードの不一致が生まれないようにというところで、基本ではあるんだけれども、サッカーに例えると90分の89分までちゃんと、第2部のテーマである「基本」ができるように日々努力しないといけないよね…というところで、第2部が始まりました。

第4章:ドメインを隔離する

レイヤ化アーキテクチャにより、各層の位置づけを明確にし、特にドメイン層の位置づけをしっかり保ちましょうよというお話し。特に「ドメイン層以外にドメインの知識が入り込んでいないか」というところを意識していきましょうと。

プレゼン資料では P59 あたりは、現実に直面したお話しがあり、

  • コントローラー層やページ記述に「業務知識」が染み出していることがある
  • 複雑なSQL文に「業務知識」が紛れ込んでいることがある

といった感じで、わかりやすい例を元に「業務知識の紛れ込み」に敏感になっていきましょう、継続的にリファクタリングしていきましょうと。そのために2ステップビュー(2段階でやっていく)という小技・アプローチがありますよ。

  1. ドメインオブジェクト(ActionListオブジェクトなど)で論理構造を返却
  2. 各層に適宜ヘルパークラスを用意し、ドメインオブジェクトを変換

個人的には、ドメイン層をちゃんと各レイヤーで分けたいのであれば、他の層との「ギャップ」を埋めなければいけないところがでてくると思っていたので、ヘルパークラスの存在って重要だなと思いました。(もうちょっと具体的な中身を知りたかったかな…とは思いました)

第5章:モデルをプログラムで表現する

(P68)にもあるように、モデルが分割されてデータベースとのマッピングはめんどくさいように見える(別にDDD以外の設計もあるんだからやらないという選択肢もあるんだろう)けど、DDDはそこ(関心事を発見してクラスに抽出する)を行くのが基本の考え方ですよと。

値オブジェクトは、積極的に型を宣言すること (P72) により「知識豊か」にしていき、何が関心事なのかをどんどん明確にしていくことで、よりよく(人間の関心事に近づく)なっていきますよと。

エンティティは、見つけやすいけど、使いすぎるとどんどんエンティティが肥大化してしまうので注意が必要ですよと。なので「識別」をきちんとすることで、利用者の関心事に集中し、文脈なども絡めてとことん「スリム」にしていくのが良いですよ。

ドメイン層のサービスクラスでは、なんとかDO・なんとかプロシージャー…うーんこれは危険ですと。手続き型プログラミングになっちゃってそこにロジックが集まって暗黙のビジネスルールの宝庫になりがちだからおすすめしませんと。

これは、もう一方の考え方として、先ほどにもあった「ドメインオブジェクト」の考えを意識し、サービスクラスの「引数はドメインオブジェクトじゃだめよ」というルールを作ることでガードを作ることが有効ですよと。

例えば、男性料金・女性料金などの多態の場合は、インスタンス変数を持たずに、ロジックとしてしか持たないようにするなどしたりしてますよと。

また、2つの用語についての説明もありました。

  • ファーストクラスコレクション
    ListやSetをラップしたドメインオブジェクト
    昨今ではハードウェア・ソフトウェアの性能もあがっているので、
    SQLの抽出を細かくせずに、取得したでデータ上で操作する方法もアリで、
    楽な設計・安全な設計にもっていけるようにしておく
  • 区分オブジェクト
    場合分けの書き方あれこれ - Google 検索」で検索!

また、この章では、オブジェクトのライフサイクルの管理(永続化など)は、複雑になりがちであるので、別のクラス・枠組みで外だしを行って、モデル・エンティティ・バリューオブジェクトの関係を「シャープ」にするための工夫を説いているのですよと。

第6章:ドメインオブジェクトのライフサイクル

ごめんなさい。言葉の意味がわからないことが多くて難しかったです。トランスファインタフェースって何?って感じでしたが、これは後で勉強することにして…。

この章では、モデルと実装の関係を単純明快に保つために「集約」「ファクトリ」「リポジトリ」がありますよというのが趣旨となっていますと。

第7章:言語を使用する:応用例

この章はチームで共有してほしいと、12の項目があるけれども、「2:ドメインを隔離する:アプリケーション層の導入」が大きなポイントですよとのことでした。なぜならここで隔離をチームできちんと共有できていないと良いモデル駆動設計はできないから。

実は、入出力項目・画面帳票定義・テーブル設計は、DDDではほとんどでてこない。なぜならプレゼンテーション層・データ層からドメインを作りに行くのではなく、その逆であるということ。画面やデータから見つかる言葉も多いから重要なこともあるんだけど、ドメイン駆動設計のアプローチ(関心事の抽出)としてはちょっと違うんだなと。

画面にはでてきていないけど、関心事はこういうことだから、こういう画面がいいのではないですかというアプローチがDDDのあるべき姿であると。(すぐできるかどうかは別で、毎日戦いですと)

第3部:より深い洞察へ向かうリファクタリング

見つけたときは明快に表現できていない、整理できていないものを第3部で洗練させていきますよと。

コード的な「リファクタリング」の観点ではなく、ドメインの表現としていい表現になっているかという観点からの「リファクタリング」を進めていきましょうと。例えば、コードが重複していたとしても、ドメインの関心事として残しておくべきものなのであれば、重複コードも良しという場合もあるよと。

このあたりから時間が足りなくてかなり早回しになってしまったので、要点だけまとめる形とさせて頂きます…m(_ _)m

第8章:ブレークスルー

「わかった」という成功体験・経験を思い出しながら読んでみるとよいですよ。そして変化のリズムというのはいつだって「ゆるやか」なんですよということ。基本的なことの地道な繰り返しがブレークスルーにつながっていきますよと。そしてその変化の1つ1つをチームで納得(共有)しながら実験を進めていくというアプローチ。

第9章:暗黙的な概念を明示的にする

ここはキモですよ。何度も読み返すと良いですよ。チェックリストとして起こしておくのもありで、コードレベルも含めて実践的なテクニックを書いているのはこの章である。暗黙的な概念の掘り返し、チャレンジの手法などが書いてありますよと。

補足として

  • 制約
    LocalDateで誕生日。10億年前なんておかしいだろ…気持ち悪さの発見をしよう
  • プロセス
    オブジェクト指向の苦手である時間軸に沿ったものごとの考え方を身に着けよう
  • 仕様
    ビジネスルールを的確にシンプルにとらえてコードでスッキリ表現しよう
第10章:しなやかな設計

言語仕様の一部である。Javaは比較的古い設計の言語にあたるので、他の言語仕様で勉強してみても面白い。KotlinなんかはJavaの古いところを新しく定義しようというような流れもあるし、増田氏も非常に感動しておられました。

また、総合レッスンな形で「バリューオブジェクト」「ファーストクラスコレクション」には良い題材かなとおっしゃっていました。

第11章:分析パターンを適用する

分析パターンはゴールではなく出発点で、便利だから分析パターンを使うのはいいよということを説いていますと。

ネタを探すために「APIとして公開されたサービス」や「言語・概念」を掘り起こすために、その分野の文献(目次・図表・用語集)を読んだりすることを心掛けましょう(英語ならそのままパッケージ名にも割り当てられるしね)…ってところなのかな。

第12章:デザインパターンをモデルに関係づける

ドメイン駆動の観点からデザインパターンを読み直してみると良いですよ。ドメインを表現する一つの「手段」としても使えますよと。(概念的にも技術的にも)

第13章:より深い洞察に向かうリファクタリング

リファクタリングのきっかけは「違和感」になりますよ(当然ですよね)。但し、方向性を間違えないように(ゴクリ…)、いくつかルールを作っといたほうがいいですよと。

  • 選抜チーム(有能な人)と一緒に取り込むことが大切ですよ
  • 言葉を駆使して実験をしていこういう「DDDの根底のスタイル」を大事に
  • ドメインエキスパート(その道のプロ?)の「納得感」が大切ですよ

増田氏もおっしゃっていましたが、タイミングとして「疎結合」というキーワードかなと思いました。疎結合=しなやかにできる機会があるならやっていきましょうというところです。

個人的には、この「エキスパート」がいるかいないかというところで、なんちゃらマスターとかいう公開されている「資格」があれば、安心だなぁと思いました。

第4部:戦略的設計

日々変わるチームや政治的な要因など、大きくなればなるほど、変化すればするほど、意思決定が難しくなるんだけど、やはり「言葉」による「発見」と「改良」を強調して書いてありますよということ。

そして、戦略を推進していく上では、コードを現場で書いている人間が「戦略」を考えるべきで、そうすることによって「戦略=実装」になっていきますよ。それを地道に続けていくことで「ブレークスルー」が発生し、より「成長するものづくり」ができますよと。

第14章:モデルの整合性を維持する

技術的な要素はあまりなく、意思疎通・協力関係で起こる問題のパターンはどういうものがあって、(チーム・言語・意思疎通の観点から)どうやって解決していくかという手法が書いてありますよと。

第15章:蒸留

コアドメインを見つけだしにいく。プログラム的な構造的なコアという意味ではないですと。あくまでもドメイン設計の文脈で「ビジネスにとってここがコアなんだ、価値を見出すのはここなんだ」という観点で探しに行くんだということ。

モジュールの間の依存関係を「意識・検証」しながら整理していきましょうと(パッケージ図は書いたほうがいいよ!!!)。

そして、最終的にそれらが「抽象化」されたパッケージになることで「破壊力のあるコアドメイン」となると。(もちろん一発では作れないから成長させる気持ちで作り上げることになります)

第16章:大規模な構造

規模が大きくなってきたときに「俯瞰力」を持っていこうというところが中心なテーマでありますと。

第17章:戦略をまとめあげる

14・15・16章を組み合わせた章になりますと。重要なのは2点あり、コードと戦略は絶対に引きはがしてはならないということと、しつこいようですが「言葉」の重要性をすごく説いてますと。

さいごに

非常に長くなってしまいましたが、4時間で1冊分のお話しがあったわけなので、非常に濃密な勉強会であったのは伝わっているかな…と思います。

参加するまでは「DDD」って全く新しい設計手法なのかなぁ…とぼんやり捉えていましたが、既存の「オブジェクト指向」「XP」をうまく組み合わせることで、より変更に強い設計手法なんだなというところで腹に落ちた感じはします。

まだ本は読んでないのですが、この著者であるエヴァンスは「成長するものづくり」を様々な方向からアプローチした結果「DDD」に行きついているのかなとも思いました。

次回の開催はいつになるのかわからないのですが、次回までにこの記事のポイントをうまくとらえながら読書できればと思います。