こちらのイベントに参加しました！
気づいたときには無料参加枠は埋まっていたのですが、ブログ書きます枠が新設されたので、1人目として申し込めました。
以下の記載では基本的には登壇者が話したことを常体で書き、自分の感想とかは敬体で書いています。
登壇者の発表内容の記載がものによって全然違うのは、私の理解力の他に、スライドが公開されるかどうか知らなかったこともあります。結局全部公開されたのですごい。
前置き
イベントの説明にある「技術的負債が社会問題に！？」の内容とほぼ同様
ソフトウェアの核心にある複雑さに立ち向かう
株式会社ギルドワークス 増田 亨
www.slideshare.net
ドメイン駆動設計でなぜつくるのか
- 動かした後も成長を続けられるようにする
- ソフトウェアの変更を楽で安全にする
- コスト・スピード・セキュリティにプラスに作用する
- 技術の新しい古いは関係ない
「核心にある複雑さ」とは何か
ソフトウェア開発では色々な複雑さがある
ドメイン駆動設計で重視している複雑さは？
- →ドメイン：ユーザーの活動、ビジネスそのもの、複雑さの源泉
ドメインロジックとは何か？
- →具体的にとらえると、ビジネスルール
ビジネスルールを適用する条件によってさまざまな分岐がある
- そのため、複雑化する
ビジネスルールをドメイン層に切り出すと、入出力は面倒だけど複雑ではなくなる
- したがって、変更が安全になる
その複雑さにどう立ち向かうか
- 関心の分離の工夫
モジュールの構造の工夫
従来のモジュール構造とビジネスルール
計算から入出力を隔離する
- 例えば、計算結果オブジェクトと、出力（画面、JSON、データベース）は分ける
上記二つの工夫がどのように違うのか、あまり理解できていないところがありますが、どちらにしても複雑さに立ち向かいやすくするための工夫なのかなと解釈しています。
本格的に立ち向かう
- 深いモデルを探求する
- ビジネスルールの中核を見定め、中核に集中する
- ビジネスルール全体の関係を俯瞰的に整理する
エヴァンス本は、第1部～第4部からなる。第1部、2部は入門編で、本格的に立ち向かうなら第3部を読むとよい。
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート
ほげさん
www.slideshare.net
抽象的な話が多くてまとめづらかったのですが、 P36、37のところは、何となく理解できて、重要なところは依存関係が本当に必要なのか考えることと、変更の巻き添えを食らわないように、抽象化することなのかなと。
DDDサンプルコード ライブリファクタリング
関西Javaエンジニアの会 irof
株式会社ギルドワークス 増田 亨
後ろのほうにいたので何書いているかは具体的に見えませんでしたが、まあ後でコミットしてくれるでしょうということで。
レポジトリ github.com
動くアプリ
https://isolating-the-domain.herokuapp.com/
このIssueに取り組んだ。
従業員登録手順をcordinatorパターンに · Issue #101 · system-sekkei/isolating-the-domain · GitHub
Issueの内容としては、コントローラーの中で複数のサービスを呼んでしまっているから、コーディネーターパターンを用いて、コントローラーからみてシンプルにしたいということ。
Jigで出力するソースコードの可視化していて、議論に役立っていました。Jigは↓
他にもいろいろやっていました。パッケージの関係図を見ながら、依存関係が正しいかどうか議論をしていました。
コミットは以下の「賃金パッケージを導入」～「EmployeeRecordCoordinator導入」までです。
https://github.com/system-sekkei/isolating-the-domain/commits/master
劇的ビフォーアフター 〜BIGLOBEのDDDの昔と今〜
ビッグローブ株式会社 曽根 大作
DDDとの出会い
- 独自言語*1の世界、マニュアルはExcel、どこに置かれているか分からない
- 2013年にJavaが導入された。DDD・Scrumで開発
- のれんわけ方式での拡大計画
- ある程度チームが成熟したら、分裂し、新しい人を加入させる
ビフォーアフター①モデルの書き方
改善前
名詞ベースのみのモデリング。 情報が足りない、責務・関連依存・多重度などが欲しいという問題があった。
改善後
3つのモデルを作成するようにした。
ビフォーアフター②状態の表し方
改善前
ひとつのエンティティにすべてのイベントがぶら下がっていた
例えば、契約エンティティに、申し込み、解約、その他もろもろが全部入っている状態だった。
すると、エンティティが肥大化してきて、実装時に本来関係ないイベントまで意識する必要が出てくるようになってしまった。
改善後
状態ごとに必要な要素のみを持ったエンティティを生成するようにした。
例えば、ファクトリやリポジトリに渡して書く状態のエンティティを作成、永続化した。
すると、エンティティの責務がはっきりするようになった。
不要なメソッドやフィールドがなくなり、変更やテストもしやすくなった。
ビフォーアフター③チェック
様々な業務ロジックをどのように表現するかについて
改善前
アプリケーション層にもロジックが記載されていた。
可読性が低くなる、テストが複雑になる、ドメインモデルに表現することができないという課題が生じていた。
改善後
ドメイン層にチェックに必要な業務ロジックを集約することで、上記の問題を解決した。
実録！LOHACOにおけるDDDとCleanなArchitecture
アスクル株式会社 佐藤 大典、中村 俊之
前半（抽象的な話）
LOHACO*2は巨大なモノリシックとなっている状態だったが、そこから変更のしやすいシステムを目指した取り組みを紹介していました。
ユビキタス言語のところについて、実際どうやったらよりうまくいったか*3というところは聞いてみたかったですね。
ビジネス側とのやり取りが必要な分野だと思いますので、うまくいった場合の応用はかなり幅広く利きそうです。
後半（具体的な話）
Maven multi-moduleについては、気をつけようという感じでもなんとかなる気もしますが、仕組みで強制するメリットもあると思います。
あんまり関係ないですが、レガシーDB対応はそれ一つでかなり大きな知見なんじゃないかという感じがありますね。
ビジネスルールの複雑さに立ち向かう実践技法
株式会社ギルドワークス 増田 亨
www.slideshare.net
スライド番号に付随して補足を記載します。
8
- 右が戦術、左が戦略
- すべてのプロフェッショナルになれというわけではないが、第1象限の能力を高めようとしたら、他の象限についても補強しないといけない
11
「私は型原理主義者なので」とのこと。
17
汎用型とはint型など 楽で安全、というのは、制約がかかっていることによる。intとかだと何が入っているか分からない。
23
種類を限定すると、境界値テストがほとんど意味をなさなくなる。
34
むちゃくちゃ細かいロジックになってくると、マニュアルを読むだけではなく現場に聞いてみないと分からないことがある。
44
SEの領域といった印象。本自体は難解らしい。
感想
前半のプレゼンでも感じたことですが、非常にメモが取りやすいです。例えば資料内では表や箇条書きになっていることでも、それについて論理的な構成立てで話してくださるので、自分の中に入っていきやすいです。
全体まとめ
レガシー改善というのは最新技術で華麗に解決するというものではなく、地道な取り組みで成果を積み重ねていくものだと思います。
非常に複雑なビジネスロジックに対する戦いは、いつまでもなくならないと思いますが、逆に知見も豊富になりうると思います。これからも頑張っていきたい。
