App Client Melting Pot #1「設計」参加レポート #app_mp

# イベント概要

今回はFiNC Technologiesさんが主催のApp Client Melting Pot #1に参加してきました。
会場もFiNCさんで、以前 [Microservices Meetup vol.9](https://qiita.com/sadashi/items/afe5eb34f74d5f1801ba) に参加したときから２回目です。
プロジェクションがカッコいいのが印象的でした。
https://app-client-mp.connpass.com/event/112973/

## Twitter Hash Tag

[#app_mp](https://twitter.com/hashtag/app_mp?src=hash)

## ウェルカムトーク by [@qsona](https://twitter.com/qsona) さん

（スライドは公開されれば追加します）

FiNCさんではどのような試みをしているかなどのお話でした。
Fusion（融合）という単語がよく使われていました。

- Client Fusion
    - Fusion Android & iOS 
- Client-Server Fusion
    - アプリで使うのが主目的だが、取り回しがきくようにする必要がある
- Fusionと設計
    - ドメインモデルはClientとServerで認識を揃える
    - 見た目都合はBFFかClientで対応する

そして今後やっていくこととして以下のような項目が挙げられていました。

- Clean Architecture
- モジュール分割
- マイクロサービスとの協調
- BFFの有効活用


## FiNCのクライアントアーキテクチャを揃える試み by [@takasek](https://twitter.com/takasek)さん

[スライド](https://speakerdeck.com/takasek/20190110-number-app-mp)

アプリクライアントの設計を揃えるメリットの説明から、FiNCさんで利用されているアーキテクチャの話がありました。
PDS(Presentation Domain Separation)やアーキテクチャの種類(GUI Architecture, System Architecture)などの説明もあったので、かなり理解がしやすかったと思います。
`Resource<T, E>`型などの便利そうなものもぜひ活用したいですね。

とは言え、アーキテクチャを揃えるのも大変な部分があったり、なかなか全てを変えるというのは難しい中、「設計は漸進的に進化させるべき」という言葉は印象深かったです。


## 実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~ by [@izmeal2000](https://twitter.com/izmeal2000)さん

[スライド](https://speakerdeck.com/kensukeizumi/shi-jian-bff-bffhafincfalseapuridehe-wojie-jue-sitafalseka)

以前、[Microservices Meetup vol.9](https://qiita.com/sadashi/items/afe5eb34f74d5f1801ba#%E5%AE%9F%E8%B7%B5bff--bff%E3%81%AFfinc%E3%81%AE%E3%82%A2%E3%83%97%E3%83%AA%E3%81%A7%E4%BD%95%E3%82%92%E8%A7%A3%E6%B1%BA%E3%81%97%E3%81%9F%E3%81%AE%E3%81%8B-)でお話されてた内容でした
一度聞いてたので、今回はゆっっくり聞くことができました。

BFFを使って解決している課題は主に以下の３点のようです

- 通信パフォーマンス
- 集約ロジックの共有
- レスポンスによる表示切り替え

それぞれ適切に扱うために気をつけるポイントなどが聞けて大変参考になりました。
やはり、実践されている話を聞くと理解しやすいですね。

## 2つの同期 4つの状態 by [@ktanaka117](https://twitter.com/ktanaka117) さん

[スライド](https://www.slideshare.net/kenjitanaka58/2-4-appmp)

通常設計を考える上では責務の分担やパターンから入ることが多いですが、今回は「データの同期方法」と「データの状態」という方向から考えてみるというお話でした。

- データの同期方法　２種類
    - オブザーバー同期
    - フロー同期
- データの状態　４種類
    - Screen State
    - Presentaion State
    - Session State
    - Record State

Clean Architectureで考えると４つの状態が各レイヤーと対応するのでイメージしやすかったです。

State同士の距離と同期コストで考えると、距離が近い・コストが低いというのは細かな制御がしにくい、責務が分散しづらい状態なので、役割がFatになる（よくあるFatActivity, FatViewController的なやつ）というのはすごくわかりやすいですね。
この観点で考えた時にGUIアーキテクチャの違いは「ScreenStateとどのStateがどういった同期方法で繋がるのかの違い」というのは自分の中で色々としっくりきました。

# （飛び込みLT）設計の話をする前にすり合わせしたい言葉 by [@shinkuFencer](https://twitter.com/shinkuFencer)さん

[スライド](https://speakerdeck.com/shinkufencer/reconcile-our-word-before-start-designing-architecture)

自分もよく悩んでました。あと設計を勉強し始めた時に、割と勘違いしているポイントがあったのを思い出します。
自分の場合はDDDの勉強をしたときにEntityという言葉が若干混乱しました。
その時は[@takasek](https://twitter.com/takasek)さんの記事がとても参考になりました。

- [お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える](https://qiita.com/takasek/items/70ab5a61756ee620aee6)

DDDでいうとユビキタス言語とかもそうですが、関係者間で共通の認識を持った言語で話すのはとても大事なことですね。

# （急遽）パネルディスカッション

- パネラー
    - [@takasek](https://twitter.com/takasek)さん
    - [@ktanaka117](https://twitter.com/ktanaka117)さん
    - [@digitaljunky](https://twitter.com/digitaljunky)さん

急遽パネルディスカッションが開催されました。
主なお題としては、ClientとBFFのどちらにロジックを実装するべきかという内容で、具体例をあげながらこの場合はどうするべきかなど色々参考になるお話がきけました。

# まとめ

今回はタイトルの通り「設計」の濃い話が聞けてとても参考になりました。
設計において一般的な回答を聞こうとすると、やはりケースバイケースという結論になりがちですが、要はメンバースキル、コスト、要件、環境など様々な要因を踏まえた上で最適を見つけていくことが重要だと改めて感じました。
また最適を考える上でも、パターンだけを覚えるのではなくアーキテクチャの根底のところを理解するというのも大事なポイントですね。

登壇者の皆様、ありがとうございました。