オフラインのカンファレンスの参加はコロナ禍前からの4年ぶりの参加となりました。
OOCも4年ぶりということで、縁も感じつつ、4年前と比較してより実務のどこで実践していけそうかという具体をイメージしながら公演を聴いていました。
自身のステータスの変化を感じると共に、このような学びの宝庫である機会を提供いただきありがたい限りです。
登壇者、スタッフ、関係者の方々、ありがとうございます!!
今回は完全にお客さんで、何も貢献できていないのに学びだけ得たという状態で大変申し訳無いので、次回あった際は何かしらの形で私も貢献できればと思います。
以下聴講したセッションと所感です。
戦略的DDDを実践するための跳躍力
DDDの戦略パターンを後天的に以下にして実践していくかというお話でした。
DDDの戦略パターンを実践していく上で、ドメインエキスパートの実際の業務を見る中で、ドメインエキスパート自身にとっては常識や意識していないこと、開発には関係ないと思って情報落ちしていたりする物が見えてくるというお話が特に勉強になりました。
私は開発とドメインエキスパートで組織体系が違う組織に属しているのですが、「互いの専門領域に踏み込んでいくの気を使いがち」という話は実体験として共感できましたし、その上で
- 職域を超えて、わからないことをわかるまで追いかける力が大事
- 自分が理解したら目的の半分は達してしまうが、チームに伝播しないという意味がない
という話は、もう爪の垢を煎じて飲みます。
今後自身の業務でより広範囲を巻き込んでいく際の参考に是非させていただきます。
イベントストーミングによるオブジェクトモデリング・オブジェクト指向プログラミングの適用・開発プロセスの変遷・アーキテクチャの変革
こちらもカンファレンスに続いてご無沙汰していたイベンストーミングや関連してCQRSについてのお話でした。
私の元々の理解が浅かった可能性も十分にありますが、お話の中でイベンストーミングで洗い出すものの中でポリシーについての話があり、私が結構前に実践した際には洗い出していなかったので、より認識の齟齬が無くなりそうでよいなと感じました。
イベントストーミングを実践するうえで最初は民主主義的な進め方は難しく、ファシリテーションスキルが必要ということで実践する際に備えて磨いておこうと思います。
また、イベントストーミングというと案件の最初などに関係者が一同に介して大規模でやっていくというイメージだったのですが、お話の中で数をこなしていくうちにメンバー間で壁打ち感覚で実施されている（と私が理解した）というお話があり、認識合わせの道具としても有用だなと改めて実感。
イベントストーミングで洗い出したイベントのイベントソーシングへの落とし込みについても大変興味深かったのですが、私の実務で導入するにはあまりにも一足飛びな感覚があり、まずはイベントに対して意識を向けたコミュニケーション文化の醸成からかなとぼんやり考えているところです。
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
DDDを実践するモチベーションの話からご自身の体験談、現在の取組のお話でした。
具体が伴っていたので、私が現状置かれている状況との照らし合わせがしやすかったです
今後同様の道を進むうえでにハマりそうな箇所について、あらかじめ看板を立てていただいているようなイメージでした。
- 能力を上げるうえで何かしらのアウトプットは体系立てて整理する機会になるのでおすすめ
- 質疑にあったおすすめの書籍
については今後取り組む指標になりましたし、DB駆動設計がうまくいくパターンについては
- 設計うまくいかないかつ開発が進まないのが最悪のパターン。それよりは設計はうまくいかないけど開発進む方が良い
というお話があり、DDD導入に際してのトレードオフについても考えさせられました。
ビジネスロジックを「型」で表現するOOPのための関数型DDD
型で縛りそもそも不整合を許さないという仕組みをより厳密に実践されているお話でした。
私が普段使用している言語がPHPであり、紹介されていた機能に類する機能について言語として担保されていないものもあるとは思うのですが、Sealedなどの制約でそもそも不整合なコードを書けないように縛るというのは合理的で良いと感じる取り組みでした。勉強になります。
現状私の現場ではコンストラクタで不整合弾いてその確認のためにテストコード書くというのをかなりやっていて、バリデーションやテストコードが膨らみがちです。
同様の制約をかける取り組みについて、世の中に需要はあると思うのでPHPで実践されている例がないか調べてみようと思います。
設計の知識と技能で駆動するソフトウェア開発
分析設計パターンのお話についてはJJUGを楽しみにしようと思います。
経験則/習熟/競争については和ではなく積という話が面白く学びになりました。
ポートアンドアダプターについてのお話で、実際に交換するかどうかよりも交換できる状態になっていることが発展性において重要というお話や、 分析モデルと設計モデルは一致させるべき。その2つのギャップが負債。いきなり綺麗なものは生まれない。反復的に改善していく。というお話が改めてDDDの大事な要素を改めて思い出させてくれました。
アプリケーションサービスのクラス設計や連携モデルのプロトコル設計についての書籍についても（一部おすすめはしないけどということではありましたが）紹介されていました。
私は最近ポート＆アダプターのアダプター側のコードに対してチームとしてどう秩序をもたせていくかということで、方針の確立に困ることが多いので、是非読んでみようと思います。
（コアドメインのロジック書くのが楽しく、その周辺はあんまり。。。というお話は激しく同意でした）
オブジェクト指向コードレビューの新しいアプローチ
コードレビューの事例について詳しく紹介されているのを私がこれまであまり聞いたことがなかった＆日々コードレビューの品質担保に本当に激しく困っていたので、目から鱗でした。
7つの指標を設け、あとから集計できるようPRのコメントにPrefixでどの項目に対する指摘かわかるようにしている取り組みについては明日からすぐ準備して真似します。
今回配布されてた冊子にもガイドラインについて記載されていましたので、バイブルとして大切にしようと思います。
コードレビューのAIについても工数削減のためぜひ取り組んでみたいですが、社内の仕組みの兼ね合いもありそうなので、プライベートなコードで素振りしてみたいと思います。
