<参加レポ>アーキテクチャを突き詰める Online Conference

Findy 主催のカンファレンスに参加したので感想をまとめる。

モチベーションとしては、関わっているプロダクトが持続的に成長していくためにどういうアーキテクチャがいいのか考えることが多く、そのヒントになるアイデアが得られたら嬉しいなという感じだった。結果としては、とても学びが多く参加できてよかったです。

findy.connpass.com

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

とても分かりやすくて話がスッと入ってきた。関心の分離を中心テーマとして、それを実現するアーキテクチャや設計技法について紹介していた。ポートアンドアダプター*1というアーキテクチャパターンを例にとり「計算」と「外部」を分離することの重要性と効果を説いていた。ちなみに発表中に「計算」と呼んでいたのは業務ロジックと同義と捉えたけどあってるかな?

「コードの雑音を気にしない開発チームに明るい未来はない」という強めの言葉が印象的だった。本当にそうだと思う。

speakerdeck.com

月間17億レコードを処理する動態管理システムのアーキテクチャ

5秒に1回、何千台(何万台?)ものトラックが位置情報を送ってくる動態管理システムのアーキテクチャ紹介。Kinesis Data Streams で位置情報をストリーミングして Lambda に受け渡す構成を取っている。トラックのエンジンが切れて位置情報の供給が止まったときの補正やスループット改善のための並列化、インデックス追加といった工夫を知れて面白かった。

speakerdeck.com

ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する〜モノタロウ基幹システム刷新の実践例

モノリスな基幹システムのドメインモデリングを進め、分割されたドメインに従ってアプリケーションの実行環境を分離していくという話。モノタロウ規模のアプリケーションでもモノリスを分離していけるというのは勇気をもらえる人が多いのではないだろうか。ドメインモデリングにおいて大切なことは Biz と Dev が一緒になって議論を重ねていくことなんだと学んだ。イベントストーミング、よさそう。

speakerdeck.com

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

モデリングがうまくいかない原因として「物理的な存在に囚われているから」と強調していた。商品テーブル、ユーザテーブルといった肥大化しやすいモデルがどうして生まれるのか?それは物理的な存在をそのままモデリングしているから。うーん、たしかに。目的ベースで抽象化することで「目に見えない概念」を認識し、適切な粒度(目的に合致した単位)でモデリングすることが重要だと学んだ。つまりは、関心の分離。

speakerdeck.com

ユーザーフレンドリーな取引明細のアーキテクチャVISAカードの複雑性に向き合う実践例〜

クレジットカードに特化した決済システムの枠組みの中で、プリペイドカードでいかにユーザフレンドリな体験を作るかという発表。オーソリやクリアリングといった決済システムの裏側を知れただけでも面白かったが、トリッキーな決済システムの仕様を上手くマスクし、お金のトレーサビリティを下げない工夫に感心した。(お金のトレーサビリティってワードいいな)

speakerdeck.com

その「プロトタイプ」は何のためか

プロトタイピングとは何か、その正体は何であり、なぜ難しいのかを一緒に考えていく内容だった。不確実な世界の中で、仮説を検証し、実証されたら本番投入していく。と流れを書くだけなら単純だが、実際にやってみると目的を見失いやすかったり、いつの間にかプロトタイプが本番稼働するみたいなことが起こるらしい。事業的な仮説精度が低い状態ではプロトタイプを捨てやすい状態に保つことも重要なのだと学んだ。

TODO: スライドが公開されたら貼る

一言

Room A と B を選ばないといけないシステム辛い...どっちも聞きたい...