きっかけ

ミノ駆動さん、成瀬さん、増田さんと今までセッション聞いてきて興味ある人が登壇すること
より変更しやすいシステム開発にするための取り組みの新しい情報が欲しかった

どんなカンファレンスだったか

アプリケーション開発に関する開発手法のセッションがメインでした。
書籍を書いてる人たちや現場で開発をリードする人たちが
より開発スピードをあげるため、より安全に変更できるようにするために
どのようにシステムを設計するのかその観点だったり、手法を紹介してくれました。

カンファレンスに来てる人たちが関心がありそうなワードはこの辺り。
これらのワードに関心がある人はカンファレンスの資料をみてもいいかもしれない。

DDD
クリーンアーキテクチャ
レガシーコード

セッション

聴講したセッションと概要

大きな泥団子に立ち向かうためのソフトウェア設計　本格入門
https://speakerdeck.com/masuda220/big-ball-of-mud
開発が積み重なっていくと、変更が難しいシステムになっていってしまう。
そのために関心ごとを分離して、考える範囲を小さく切り出すことが必要である。
広めたいのは考える範囲を小さくするために挙げられた手法を常識としてとらえられる今の時代だと最低限求めたいなとは感じた
CQRS+ESアーキテクチャ解体新書
https://speakerdeck.com/nrslib/cqrs-es-disassembly-book
スケーラブルなシステムの方式としての案
ES（イベントソーシング）とメッセージ駆動（CQRSを使ってやりたいこと）を組み合わせることによって、リソースの待ち少ない仕組みにつながる
タスクが細分化できるようになるので、クラウドサービスのスケーラビリティにもしやすくなる
口頭説明が多くて資料だけだとわからないので、youtube見た方がいいです。
https://www.youtube.com/watch?v=NhDj6Ep9SyA
見えないものに着目すると上手くいく、モデリングの勘所
業務をモデルに落とし込むときは目的を観点に切り分ける。
さらに踏み込んで、禁止事項などの観点を用いて、設計に活かせる観点を挙げてくれます。
https://speakerdeck.com/minodriven/invisible-driven-design

発表資料だけ見たセッション

共有がてら貼っておきます。

ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する
https://speakerdeck.com/monotaro/bizinesunogou-zao-woakitekutiyaniluo-tosiip-misohutoueanike-bian-xing-wozhu-ru-suru
サービスを立ち上げを終えて追い求める美しいアーキテクチャ
https://speakerdeck.com/takuyatezuka/sabisuli-tishang-gewozhong-ete-zhui-iqiu-merumei-siiakitekutiya
RASKULに見るアーキテクチャの変遷　複数サービス展開への道
https://speakerdeck.com/yusukekishino/raksulnijian-ruakitekutiyanobian-qian-fu-shu-sabisuzhan-kai-henodao
＊ユーザフレンドリーな取引明細のアーキテクチャ　VISAカードの適用事例
https://speakerdeck.com/shoheimitani/yuzahurendorinaqu-yin-ming-xi-noakitekutiya-visakadonofu-za-xing-nixiang-kihe-ushi-jian-li

各セッションで得て広めたいこと

全部書きたいですけど、一部セッションだけ書きます。

大きな泥団子に立ち向かうためのソフトウェア設計

大きな泥団子は負債がたまっていて、開発が足をひっぱられてる状態。
足を引っ張られる分、変更は大変です。
ただ、その大変さを超えて開発し切ると無駄に仕事した感じは得られるんです。
でも、それってやりたいことするために本来不要な手間が発生してしまってるだけです。
同じような大変さを味わうのであれば、変更しやすいようにリファクタしたり設計を見直していくことに力を注ぐべきですよねってことが根底にあります。

変更しやすくするための手法として、イミュータブルを挙げてました。
スライド１ページが数秒で流れました。それくらい常識だよね。説明する必要ないよねって。
イミュータブルはJavaで言えば全てのメンバ変数にfinalがついた状態になってることを指してます。
これが今の変更容易性を求める現場では常識になってます。
他にも挙げられていますが、挙げられてる手法と自分達が開発しているシステムにギャップがあるのであれば、世の中の常識との差分です。
変更しにくいままでいいシステムは存在しないので、差分に気付き、その差を詰めることに目を向けて欲しいです。

CQRS+ESアーキテクチャ解体新書

イベントソーシングはステートソーシングと比べて、情報が残りやすくするメリットくらいしかわかってなかった。
セッションであったようなイベント駆動、メッセージ駆動の考えにはステートソーシングだと対応できない。
申込、キャンセルとされた場合、それぞれで必要な処理は別だが、最後の状態のキャンセルしかないので、それぞれのイベントに同期して処理完了させないといけない。
イベントソーシングなら、申し込みとキャンセルがそれぞれのイベントとして永続化されているので、非同期で申込イベントに対して、申込処理ができる。
イベントソーシングには、非同期処理ができるメリットがありました。
非同期処理ができて、細かいタスクになっていくと、空いてるリソースを有効に使いやすいのと、
障害が起きた時の影響範囲が縮まるなどの他のメリットにもつながったりします。

見えないものに着目すると上手くいく、モデリングの勘所

モデリングに限らず使える設計の観点になると思います。
セッションの中であげてましたが、道路交通法は交通事故（異常系）を防ぐことを目的として、法律ができてます。
異常系を防ぐために守ったり、決めておいた方がいいことを法律（仕様）になっている訳です。
支払い系のシステムであれば、ユーザが不利益を被る二重請求を防ぎたいという目的があって、
シーケンシャルなチェックIDを使って重複チェックしたり、キュー処理が一度しかされない仕組みを使う設計にもつながると思います。
紹介されている観点をモデリングに限らず、データ駆動のシステムの設計をするときに、深掘りする観点として取り入れるだけでも
今まで考えてなかった観点に気づけるきっかけになるので、ぜひ試して取り入れてほしいです。