タケユー・ウェブ日報

Ruby on Rails や Flutter といったWeb・モバイルアプリ技術を武器にお客様のビジネス立ち上げを支援する、タケユー・ウェブ株式会社の技術ブログです。

アプリケーションの分割についての迷走メモ

マイクロサービス化の取り組み失敗メモ。新たな失敗やつらみ、なやみを追記していくことにする。

ロール単位で分割

  • ユーザー用
  • パートナー用
  • 管理者用

というアプリ利用者ごとに機能を分割してEngineにしてみた。

結果

ロールごとにUIの方針を変える(管理者用だけ通常のRails他はSPA)、という今回の要件はわかりやすくなったし、一見整理されているように見えるが

  • 当然だけど密結合のつらみ。ある機能の変更をしようとしたとき各ロールのEngineでそれぞれ変更が必要。
  • ディレクトリを行ったり来たり忙しい

複雑化しただけであんまり意味なかった。

機能単位で分割

まだやってない。

機能間の依存関係があるとき、ある機能を捨てるときにやっぱり他への変更は必要で、結局分割しきれないんじゃないかなぁ、とか思っている。

でもたぶんロールでの分割よりは実装は分けやすいと思う。

モデルの共有手段として

ユーザーモデルなどシステム全体を通じて必要なモデルなどの共有手段としてEngineを使ってみるテスト。

モデルを使う各機能はそれぞれEngineで作成

結果

ある機能のためにモデルを拡張したいとき、その拡張はどう扱うべきか。

各Engine側でサブクラスやMixinを使って拡張?それとも共有のところでやっちゃう?後者は意味ないよね。

そもそもそのモデルは、Engine側?ホスト側?

そもそも分割について

やらずにすむならそれにこしたことはないのでは

コストについて

分割したということはつなげる必要があり、そこのコストがどうしても必要になる。

結合度理想と現実

そもそも結合度を下げなさいという話だけど、クライアントからの要望など実装が汚くなってもやらざるを得ない場合もあり・・・

サブアプリケーションの手段としてEngine使うのやめます宣言

汎用的な機能を切り出す、それで収まらないときにホスト側でオーバーライドとか継承とかを使って拡張する、ぐらいに抑えるべきだと思う。というかもともとそういう機能だよね、これって。

余談

外部での処理システムを用いた分割

当然だがLambdaやなど外部での処理システムを導入する場合、分割は発生する。Engineとは意味あいが違うが。

ソースコードのバージョン管理(バージョンあわせ)、デプロイをどうやればミス無く齟齬無くできるのか?悩み中。

ActiveResourceで分割してみた顛末

マイクロサービスなんていう言葉が流行る前、WebAPIが盛り上がってきてActiveResourceが登場した時、今で言うそれのような機能別にサブアプリに分割してそれらをActiveResourceで繋ぐようなことをやったが、開発・保守コスト、システムの複雑化、通信エラーのハンドリング、トランザクションの問題、そもそものパフォーマンスの問題などで失敗した。