こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
本イベントでは7/20(土)発売の『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』の訳者である増田さんをお招きし、ご講演いただきます。
書籍の内容を踏まえまして、ドメイン駆動設計を現場レベルに落とし込み、プロダクトにどう実装していけば良いかという実践的な手法や考え方をお話しいただく予定です。
会の様子
書籍の概要
ドメイン駆動設計の初学者を対象にしている本であるものの、ドメイン駆動設計抜きにしてもよいことが書いてあると(訳者の綿引さんも)考えているそうです。
また、イベントソーシングやCQRS、イベントストーミング、マイクロサービスなどに関しても話が書かれており、次世代のドメイン駆動設計本だとも感じるそうです。
書籍に何が書いてあるか？
事業活動とソフトウェアを一緒に発展させていくための方法やなぜそうするのか？という説明が一貫して書かれているということです。
具体的には、
- 基本的な考え方
- 実装方法の選択
- 現場での取り組み方
- 分散型システムへの挑戦
が記載されているということでした。さらに言えば、第1章〜第4章までは事業開発に関して話がされていて、その後に設計判断が書かれているということです。
事業活動を理解するための基本用語
ドメインなどの従来の訳語は、事業活動を理解するための理解を妨げてしまった感覚が増田さんの中ではあったそうで、日本でもわかりやすく伝えたいという想いから従来とは違う訳語が充てられているそうです。
事業を学ばないといけないのか？
ソフトウェアを設計するなら事業活動の理解は不可欠だという話が本書では書かれているそうです。
特に、競合他社とどうやって差別化して競争優位を生み出して維持するのか？という部分に関しては大切だと感じているということでした。
この活動は技術的に言えばユースケース(図)の集まりだと捉えられるそうで、中核の業務領域が特に優位性をもたらすというお話がありました。
優位性をもたらす業務領域
業務ロジックの複雑さと競合他社との差別化の2軸で比較をすることで、おのずと業務ロジックの実装やアプリケーションの技術方式, テストの基本方針が決まってくるということです。
開発技法
これまでのウォーターフォール型の開発は、開発者が同じ言葉を使って開発する必要がないように分業を進めてきた側面があるという話がありました。
複雑さに立ち向かう
全体モデルを書くのではなく、文脈を区切って文脈ごとにチームを区切って複雑さに立ち向かうことが重要だという話がありました。(文脈を分けることで言葉の曖昧さや多義性がなくなる)
また、業務領域はビジネスそのものなので、自分たちから考えるというよりはソフトウェア開発者が理解できるようにビジネスを整理することが重要だということです。
システムの連携方法
こちらも結局文脈次第にはなるものの、モデルの共有や良きパートナーとしての連携ができるようにすることが大切で、文脈の地図を考えながら中核領域がどこなのかを特定することでそれを実現することができるという話がありました。
また、こういったことが分かっている前提で、区切られた文脈同士を連携するような技術に関しても記載があるそうです。
事業とソフトウェアの成長
事業が成長すれば業務領域のカテゴリーは変化するため、継続的にソフトウェアアーキテクチャは変化するという話がありました。
開発チームの学習と成長
現実世界でドメイン駆動設計をした際にぶつかる生々しい失敗談(例えば完璧なドメインモデルの探求など)が書かれているそうで、ドメイン駆動設計のすべての技法を使う必要はないという話が記載されているということでした。
ドメイン駆動設計と分散型アーキテクチャ
理解の難度は高い章だと思われるそうですが、モダンな技術トレンドの話が記載されているということでした。
Q&A
講演の内容に関してQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
文脈の違いを許容する場合、永続化データはどう扱うのか？
DBを分けたりテーブルを分けたりするようなイメージ。ユーザー単位で連携したいような場合は、連携方法の章を読んでほしい。
Railsでこの考え方どう実現できるのか？
Railsでやっている人はいるが、Railsの一般設計とどう折り合わせていくのか？というところは課題だと思っている。
カテゴリが変わったら作り直すということか?
そのとおり。ただし、早く発見できるためのテクニックが具体的に書いてある。
合成用のクラスとはどういうものなのか？
集約とほぼ一緒。値オブジェクトをどう組み合わせて表現していくのか？を合成クラスと表現した。ちなみに、正直言葉としてこれがいいのかは迷っている。
見積もりの根拠を技術者に発注してもらえないのか？
増田さんの正直な感想としては、発注者はHappyではないと思ってしまっている。ただ、技術者に置き換えるべきかというとそれは別の話だと思っている。
Evans本など既存のドメイン駆動設計本との違いは？
エンティティに対する重要度を下げている。また、文脈のつなぎ方はEvans本とは全く異なる説明がされている。
会全体を通した感想
ドメイン駆動設計を学ぶというよりは有用な設計技法を学ぶようなつもりで読んだほうが得られるものは多そうだなあというのを感じられるイベントでした。
また、本の読み方のイメージや、Evans本との比較など面白い読み方の提示があったのも個人的には満足でした。
