2019/05/18に行われたJJUG CCC 2019 Springに参加してきました。そこで聞いてきたセッション概要とその感想のまとめです。
箇条書きで見づらいかもしれないですがご容赦ください。
間違っている箇所等あればご指摘いただければ幸いです。
参加セッション概要と感想
Jakarta EE Update -May 2019-
発表資料
概要
- Jakarta EEのお話
- Java EEはOracleの商標なので今後利用できなくなる
- Java EEからJakarta EEへ規格を引き継いだ
- Java EEからJakarta EEに変わる際の変更点
- Owner: Oracle -> Eclipse Foundation
- 標準化: JCP -> JESP
- 仕様: JSR -> EE4J Project
- パッケージの名前: javax.* -> jakarta.*
- jakarta.* となった後も古いjavax.* のAPIは使える
- Jakarta EE 8はJava EE 8と違いはほぼない
- Jakarta EE 9でいくつかAPIが変わる
- 互換性のためjavax.* の古いAPIは残る
- Jakarta EEに移管すればJava EEの時よりも開発速度は早くなる
- このブログが参考になる
感想
- 今後javax.* のネーミングが使えなくなるので既存コードの修正が若干面倒かも
- Java EE時代よりも開発速度が早まるのでそこは期待
ArchUnit で Java/ Kotlin アプリケーションのアーキテクチャを CI する
発表資料
概要
- 内部アーキテクチャをテストするお話
- ArchUnitはパッケージ依存関係をJUnitのテストコードとして表現できるテストフレームワーク
- 今まではアーキテクチャの知識が属人化・暗黙知化していて、知っている人しかチェックできなかった
- ArchUnit導入メリット
- アーキテクチャレビューを自動化できる
- アーキテクチャの暗黙知を形式知化できる
- アプリケーション固有の実装ルールをテストすることもできる
- 例えば認証など必ず通ることを保証するようなテストを書くこともできる
感想
- アーキテクチャが守られないと何かと負債を生む原因になりがちなのでこれを担保できるのはすばらしい！
- パッケージ構成が決まればパッケージ依存関係のテストは1度取り入れてしまえばずっと使えるのでテストを書く手間はそんなにないと感じた
- Springの
@PreAuthorizedアノテーションつけ忘れ防止に使えそう
Cloud Native時代の開発環境とアプリケーション基盤
発表資料
概要
- Eclipse Cheの紹介
- ブラウザベースのIDE
- DockerやKuebernetesのコンテナ環境も提供
- IDE, ファイル, 環境をPodとして提供
- 「自分のPCでは動くんだけど。。」がなくなる
- 触ってみたい場合は以下が良い
- Che on OpenShift Online
- Minishift
- MinikubeベースのOpenShift
- Stackと呼ばれるすでに用意されている環境を選んで開発する
- ランタイム、コンパイラ、ツールなど
- 既存のWorkspaceをフリーズドライして発行されるURLを用いて共有することができる
- Red HatはVS Codeのプラグインを積極的に提供し、IDEを強化している
感想
- 見た目は一般的なIDEとほとんど変わらない印象
- 開発環境構築の時間が削れるので使えるようになれば大きいと感じた
- 環境構築で詰まるということがなくなるのでそういうストレスはなくなりそう
先行開発！Javaでクリーンアーキテクチャ -- ゼロから始める新規開発
資料
概要
- クリーンアーキテクチャのお話
- 新規開発で先にフロントのプロトタイプを作る必要があったのをクリーンアーキテクチャを導入することでロジックと側を簡単に付け替え可能とすることで解決した
- クリーンアーキテクチャの前にヘキサゴナルアーキテクチャについて
- 六角形のやつ
- ビジネスロジック以外を交換可能にしておく(プラガプル)
- ビジネスロジックを点在させない
- ヘキサゴナルアーキテクチャの外側の具体的な実装について詳細化したものがクリーンアーキテクチャ
- ヘキサゴナルアーキテクチャの内側(アプリケーション)の話をしているのがオニオンアーキテクチャ
- クリーンアーキテクチャの層たち
- Enterprise Business Rules
- Entities
- Application Business Rules
- Use Cases
- Interface Adapters
- Controllers
- Presenters
- Gateways
- Frameworks & Drivers
- UI
- DB etc
- Enterprise Business Rules
- 依存の方向は内向きなので内側のコードが外側のコードを参照してはならない
- クリーンアーキテクチャで困った課題
- MVC FrameworkでPresenter使えない問題
- Controllerで何かしら値を返さないといけないためPresenterが使えない
- 結局Presenterを捨てた（素直にControllerで値を返す）
- ControllerがビューのためにFatになるがドメインロジックは守られるのでOKとした
- フィールド多すぎ問題
- Interatorごとのフィールドをインジェクションするので、フィールドが多くなった
- Message Busパターンで解決
- あらかじめ処理を登録しておいて、引き渡されたデータによって該当する処理が行われる
- 定義多すぎ問題
- 定義するものが多すぎる
- スキャフォールディングツールを自作して解決(NORIOというツール)
- MVC FrameworkでPresenter使えない問題
感想
- クリーンアーキテクチャは詳細に決められているので従えばきれいなコードが書けそう
- ガチガチに決められている感はあるので自由度は少し低そう
- 実装となると作成するクラスは多くなりそうという印象
- DDDとも絡んでくる箇所はあるので勉強せねば。。
ホットペッパービューティにおけるモバイルアプリ向けAPIの BFF/Backend分割
概要
- BFFとBackendで分割したというお話
- BFF = Backends For Frontends
- FrontendとAPIの間に位置するBackendサーバ
- アクセス元がブラウザだったらHTML, アプリだったらJSONみたいに分けることができる
- BackendチームのAPI開発速度が遅く、アプリチームが困っていた
- BFFを作ることでAPIの開発スピードを高める
- BFF層はアプリチームが責任を持つ
- BFF層で複数のAPIを束ねて返す
- 現状はBFF層でBackendのAPIを24本中6本のAPIを再利用できている
- API全体のパフォーマンスが大きいときはAPI版のN+1問題が発生しないようにしている
- API設計
- BFF
- アプリのユースケース単位で作成
- バージョンニングあり
- アプリだと更新されない限り古いAPIを利用するためバージョンニングするしかない
- Backend
- RESTで作成
- バージョンニングなし
- 社内からしか呼ばれないため
- 後方互換が壊れるときはBFFと連携して対応
- BFF
- 技術
- BFF
- Kotlin
- Spring Boot 2(Spring WebFlux)
- 複数APIを呼び出すのでI/O待ちが発生しないようにNon-Blocking I/OをサポートしているWebFluxを採用
- Backend
- AdoptOpenJDk11
- Spring Boot 2(Spring Mvc)
- BFF
- アーキテクチャ
- BFF
- アプリケーション層、ドメイン層だけ
- BFFにドメインモデルは不要という判断
- ドメインモデル貧血症になりやすい
- BFFのドメイン層でBackendのAPIを呼ぶ
- Backend
- アプリケーション層、ドメイン層、インフラストラクチャ層
- BFFと分けることでプレゼンテーション層は薄くなるためアプリケーション層と統合した
- BFF
- 課題
- Backendにかかる負荷が高い
- 変更があればBFFからBackendへ共有が必要である
感想
- 表示元として、アプリやWebなど複数あること、アプリチームとバックエンドチームが分かれているときに有効なのかもしれないと思った
- そうじゃない場合はBFFを作るコストが大きくて逆に苦しめられそうという印象
- BFFと関係ないけど使用技術が割と新しめで羨ましい
ストラングラーパターンによるマイクロサービスマイグレーションの勘所
発表資料
概要
- レガシーシステムをストラングラーパターンで徐々にモダンに置き換えるお話
- 今まで（レガシー）
- VMにJavaが載っている
- オンプレのOracle
- オリジナルのフレームワークを使用
- 刷新後
- マイクロサービスでサービス分割
- Azure Kubernetes Service
- Azure API ManagementでAPI Gatewayを挟む
- まずAzureに刷新後のサービスを作り、次に既存のサービスを機能ごとに刷新後の方に向け、最後にDBをオンプレからAzure側に移行
- 技術
- Open API
- Spring Boot
- Azure Kubernetes Service
- Azure API Management
- Swagger Codegenでレガシーシステム用、刷新システム用のAPI呼び出しライブラリをそれぞれ自動生成
- Papertrailでログ集約化
- Spring Cloud Sleuthで分散トレーシング
感想
- レガシーからモダンへの刷新にストラングラーパターンは非常に有効だと思った
- 徐々に移行するという部分が共感する
- Swaggerでライブラリを自動生成してくれるの改めてすごい
- ログ集約ツールも色々あるので今度調べてみよう
Functional Spring Cookbook
発表資料
概要
- Springで関数型っぽく書いてみたという話
- Spring WebFluxを使うとアノテーションベースでEasyにWebアプリを書ける
- Spring WebFlux.fnを使うとfunctionalな形でSimpleにWebアプリを書ける
- Spring WebMvc.fnもSpring WebFlux.fnと同様にfunctionalな形で書けるが、処理が同期的になる
- Spring WebFlux.fnやSpring WebMvc.fnでのBean定義やHTTP Clientなどその他諸々の書き方を紹介
-
@SpringBootApplicationをSpring WebFlux.fnのスクラッチ実装か、Spring Fuで置き換える方法も紹介
感想
- 関数型ぽく書けるので記述量少なめでシンプルに書けることはすばらしいと感じた
- クリーンアーキテクチャなどを導入するような大規模サービスの場合はアプリケーション層を呼ぶ処理などがあるため、ルーティングメソッドがFatになって逆に見づらくシンプルでなくなるのではと感じた
(2019/05/20更新↓)
- @making@github さんから直接コメントいただき、ルートの合成ができるのでそこまで困ることはないとのこと
- ドキュメントを読むとRouterFunctionMappingなるものが複数のRouterFunction>型のBeanを合成してくれるぽいので、ルーティングメソッドを分割することができる
- 実装者は特に意識することなく複数のRouterFunction>型のBeanを定義しておくだけで良い
- これならFatにならずシンプルを保てそう