アーキテクチャディスカッション Vol.1

https://istyle.connpass.com/event/97862/

に行ってきたので、そのときのレポート

※ディスカッション形式のメモです。
発言に対する発言を1つインデントするようにして書いています。

※正直、うまくまとめられている自信がないので、会話を追って雰囲気が伝われば幸いです。

ビジネスロジック層のモデリング

active record を使ったときのモデリングが難しい。どうモデリングをするかで分離の仕方が変わる。
- DB を一回忘れるのはどうか？
- DB のことは一旦忘れるけど、どこまでを考えるのかが重要になりそう。
- それって DB を最初が存在している前提では？ソフトウェアの内部構造って、オブジェクトの意味やライフサイクル単位で作っていくと良いのでは？あまり、テーブルに引っ張られて考えるのはよくないかもしれない。
  - その分析ってどうやって始めます？
    - 業務フローから考えます。業務をプログラムに落とし込むにはどうしたらいいのかを考える。
    - この言葉はどういうカテゴリなんだろうとか。
      あまりプログラミングというか、サービス仕様だったりデータのカテゴリわけをする
      - この場合のデータってなんですか？
        
        仕様に出てくる言葉のこと。
        
        モデリングっていう言葉の意味が幅広いので、焦点はここだよっていうのを考えるようにする。
        
        エンジニアが使うことばっていうのはいろいろな意味があるので、その意味を付箋で貼ってみたりとかもする。
        部分部分でやっていかないといけない。業務の一番重要なところはどこなのかを聞いて、そこに焦点をあてるようにしている。
        
        ドメインというのは、答えが出た時に、どういうことをやったんですか？
        
        僕らが行ったこととしては、経済活動という古くから使われているものをドメインとおくことにした。
        入荷なのかなのかの単位を人それぞれだったが、少しずつリファクタリングすることで擦り合わせていった。
        図書館アプリを練習で作ってみようとなった時に、
        会社は貸し借りが大事なのか？いや、在庫管理が大事だ。となって、在庫管理をドメインとして初めて行った。

Clean Architecrue を採用した話

最初始めたときは、どうしてもこの形にならなかった
presenters を使わない人もいて、translater を使う人もいた。
スクラップ & ビルドを繰り返して、最終的にはこの形になった。
大事なのは UML 図だった。
- entity はきっとトランザクション管理でもよいのだと思った。
  ヘキサゴナルアーキテクチャがきて、そのあとこの形になったと思っている。
  オニオンアーキテクチャはただ単にドメイン駆動設計のことを行っているだけなので、use case の部分。
  僕はこれ、浸透させるために教育させるのは無理だと思った。
  なので、ツールを作った。
  WEB のときは、 presenter のときはいらないと思った。
  非同期処理は contorller が返してくれたほうが都合がいいときが多い。
  なので、WEB の場合は presenter はいらないが、GUI ツールのときはいると思っ
  - 教育は諦めた的なことを言っていて、ツールを作ったという話があったが、
    こういう手順でやってねということをやると、考えずにやってしまう人が出てきそうだが、どう思うか？
    - ツール使った方が早くできるよ、というメリットを提示して納得してもらった。
      保守フェーズをやったことがないエンジニアって、伝わらないからつらい。運用する辛さが伝われば話も伝わる。
      そういう意味では、モノリシックで1000行ぐらいあるメソッドの保守とかしてもらったほうがいいかもですね笑（会場でも笑いが起こる）
presenter について最近本を読んでて思ったことがあるが、
本では、presenter はテストしにくい部分とテストしやすい部分を分けましょう、という話が23章であった。
その中では、 view はテストしにくいが、viewmodel まではまだテストできるという内容だった。
プログラミング言語中で、日付オブジェクトというものを view に渡したときに
文字列に変換しなければいけない。
日付オブジェクトを文字列に変換するのが presenter
その文字を活用するのが view という感じにしていたので、
presenter は必要なのでは？と思った。
- dto を使っていて、テストするので、そこは問題ではないと思った。
clean architecture に乗っ取ってるかを管理する CI ツール気になる。
- それは取り組みをやっている。構文を解析してチェックするようにしている。
  java で gladle を使ってやっているが、導入も簡単なので良い。
  ドメインの依存すべき方向とは逆方向になっているときなど、そういうのはすぐに検知できる。

DB に入れるときにレポジトリって入れると思うが、何を引数に渡している？

DB の方は基本的にイベントを保存するようにしている。
失敗談で、entity を渡すっていうようにしていたら、
レポジトリの中で新しい entity が渡されたときに、古いものとの差分をとって DB にインサートとかしていたので、その管理がつらくてやめた。
- 僕もentityというか集約をインサートしている。
  - それってentityとテーブルに差がない状態になる？
    - いや、差がある。
    - DDD のいいところが、イベントをインサートするとDBは肥大化するが、ドメインは綺麗に保てることができるのでそこがいいと思っている。

レポジトリにおいて、参照系と更新系で分けている人はいますか？

参照系だとオーバーヘッドが大きいと思うが、参照系でもユースケース層もあったほうが便利だよねという面もあって、みなさんの事例を聞きたい。
参照系と更新系を同じレポジトリで管理するか否か？ということ。
- Clean Architecure の場合は、ユースケースがインターフェイスになるので、レポジトリ使わないパターンで行った。
  - レポジトリはそのまま経由させて、書くのは RDS を使って読むのは Elastic Search とかを使ったりもしている。
    - たしかに書くのは多くなる。DB の先って何年か後に違うのにしようという話が出てくるので、そういう風にしている。
    - 両方とも同じように扱いたいので、レイヤを挟まないようにしている。
      - 逆に、レイヤを分けるようにしている人いますか？
        
        挑戦はしている。ドメインを守りたいみたいな方向でそういう風にしている。
        
        読む先と書く先が違うからという理由があるが、
        キャッシュが落ちた場合って、DBに取りにいくと思うが
        そういう場合はインターフェイスは同じだが、中身は違うようにしている。

キャッシュって、みなさん(Clean Architectureの)図でいうとどこに入れていますか？

DB のところに入れている。
ただ、ドメインをまたぐときに困る。

Clean Architecture って、人と会話するのが苦手な人にとっては苦痛かもしれない

人と会話して、こっちの人は商品って言ってるけど、こっちでは違うことを言っていて、
そこの分析をやるのが楽しい。
逆にそこを分析してからでないとコードに落とし込めないと思う。
- お金をもらって、人に本当に必要なものを作るためには、人と会話ができないといけない。

ドメイン駆動をやっていると、自分の言語がプログラムになってくるのでプログラムを英語で書くのが辛くなる。

逆に日本語のローマ字で書くと良いと、結構読みやすくて良い。

Clean Architecture の本を読んで思ったが、実践に使うには大きなサービスでないとやりずらい。ただ、実際に手を動かさないと習得しずらい、みなさんはどのようにしていますか？

教育を2週間、題材を用意してやってみた。
すると、完璧に理解するのは難しくても、コピペすればなんとかできるという状態には持っていけた。
個人的には、小さいサービスを作ってみて練習している。
自分の中で鉄板のお題（RSSリーダーを作るみたいな）を作ってみるというのをやっている。
- その時って実際に業務でやるときとのレベル感というのが出てきてしまうと思うが、
  どうやってその差分を埋めてますか？
  - 埋まらないですね。ただ、どうしても抑えておきたい部分（例えば例外ハンドリングの仕方とか）はやるようにしている。
うちの会社ではレビューで学んでもらうようにしてますね。小さい単位で業務を任せて、レビューして教えたりする。

Flux アーキテクチャって Clean Architecture に似てるって思った人います？

GUIを組んでるときに思ったんだが、形的に似ているなと思った。
そのとき思ったのが、サーバーを介さなければ同じ形になるのかな？と思った。
特に思った人がいないので、この話はやめます笑

ゲームアプリのエンジニアも Clean Architecture に興味あるらしいですよ。

ゲーム全体をそうするのはしんどいかもしれないが、一部分だけ Clean Architecture にしてテスト可能にするのは良いと思う。

みなさんどういった経緯で設計とかアーキテクチャに興味を持たれましたか？

僕の場合は 13 年続くでかいサービスを一人で保守していて、そこでアーキテクチャが必要だと思うようになった。
自分でクソコードを生み出して保守しきれなくなって、あるべき姿ってどんなんだろうと思ったのがきっかけ。
コアなモデルのほうに興味があったのが一つと、学生のときに設計やアーキテクチャの情報がたくさん入ってきたので、そこがきっかけ。
オブジェクト指向から始まって、すごい人が言ってるからいいものに違いないと思って勉強から入った。
DBに興味がもともとあった。データモデルが出発点になって、それがきっかけ。
入社したときに、Android が世に出たときくらいだった。一番最初の Activity に何千行もあるアプリを保守しなければいけなくなった。
そこをどうにかしなきゃねって思って、アーキテクトの考え方になって言った。保守しやすいアプリケーションを突き詰めたら、今に至った。
炎上しているPJがあって、どうにかしてくれというふわっとしたオーダーがあった。
そういうもののセオリーってテストを書いて始めていくのだが、どうせだからドメイン駆動設計（というのがあるらしいレベルだった）を突っ込んでみたのがきっかけ。
炎上PJってもしかしたらチャンス（新しいことに取り組める）なのかなと思った。
他者が作ったが放り出したものと同じものを作ってくれと言われた。
それが、ループが17段あったりもした。
そういう過酷な状況の中で生き残るためには設計が必要だと思った。
会社が、一人で作って一人で運用している人が多く、アーキテクチャを知っていないと自爆してしまうことがあるので、それがきっかけになった。

分析系の処理を書く（マイクロn秒）ときには、Clean Architecture は採用しないことが多い。

なぜかというと面倒臭いから。
速く返さないといけないときとかは一つのファイルにたくさん書いたりする。
- それはそれでいいと思う。
  そのソフトウェアが求められている関心事による気がする。
  人が運用する上での複雑性を解決するのが Clean Architecture だったりするし、
  速く返さないといけないとかだと技術的なアプローチが必要になるので、そのときどきにあったアプローチが必要
  Clean Arhitecture は万能薬ではないので、適材適所なアプローチが必要になってくる。

本の内容に関して

「本当の重複」と「偶然の重複」があって、

重複を排除すれば無条件で良いと思っている人がいるが、そこについて書かれているのが嬉しかった。
- このコードを重複させるべきかどうかという点を考えた時に、
  テストできるコードが設計ができるコードというわけではないと言われたりもした。

組織の形態がアプリケーションに反映されてしまうという法則がある。

組織の形態はなかなか変わらないが、アーキテクチャはよりよいものにしたいと思うときがあるが、みなさんどうしていますか？
- うちは microservice を採用していて、新しく入った人にはローテーションして多くを触ってもらうようにしている。
  そういう風に知識を蓄えてもらうようにしている。
組織変えなきゃなと思いながらコードを書いたりもしている。
何かサービスを作ろうとなったときに、新しく部署が生まれてそこで作るような文化になっている。
スクラッチで作られるサービスがたくさんあるので、横軸で共通で使えるようなライブラリとかプラットフォームがあったらいいと思うが、
いまのところ組織と同じ形になってしまっている。
アーキテクチャ設計と組織設計って同じだと思っていて、組織設計やる気持ちがないとアーキテクチャ設計できないと思う。
組織設計はマネージャーがやるというマインドだとできないと思う。
結論、組織設計から逃げない。