ふだん，主に1つのアプリケーションをずっと触っていて，常に手を入れているので，リリースフローがどんどん便利になったりしている．
モノリシックな大きなアプリケーションは嫌われがちで，役割ごとに，たとえば管理画面と表側の画面，とか，いくつかのサブシステムに分割することも考えられるけど，分割すると，分割した全てをこの便利な水準にするのは大変だな〜と思った．
2つに分けると，すくなくとも2つ用意する必要がある．もしくは，抽象化した何かを作って共通で使うことも考えられるけど，最初から抽象的な物を考えて作るのは難しい．
くっつける
- コードベースが大きくなる
- テストの実行や起動などがだんだん遅くなりがち
- デプロイは一度にまとめてやることになる
- 障害時に全部まとめて落ちる
- ライブラリやサーバーのアップデートは1回だけ
- 重厚なリリースフローや開発時の便利グッズを作りやすい
- おかしくなっても捨てて作り直すことはなく，修理する
- 自作のライブラリはアプリケーションに入れてしまってもよい
分ける
- それぞれのコードベースは小さくなる
- テストや起動などは小さいので速いはず
- 部分ごとにデプロイできる
- 障害時に特定の画面だけ落ちる
- 部品ごとにライブラリやサーバーをアップデートして回ることになる
- リリースフローや開発時の便利グッズはそれぞれ作っていくことになる
- おかしくなったら捨てて作り直せる
- 自作のライブラリはコピペして入れるか，インストールして使えるようにする必要がある
つまり，意図的に，普段なら分けるところをくっつけてしまう，という作戦も考えられるのではないか．極論を言うと，アプリケーションはチームに1個だけで，機能的にはまったく関係ないものもそこに含める，ということも考えられそう．
別のチームがメンテナンスすることになったら，その部分は別のチームのアプリケーションに実装しなおす．たぶんDBへのアクセス方法とか，使っているフレームワークなども違うので，そのまま持って行っても動きはしない．前者で同じフレームワークを使っていたとしても，その中で使っているライブラリには差があるかもしれない．
戦略的に統一すると，社内便利ライブラリが充実したり，同じ手法で管理できたりして便利かもしれない．たとえば，Railsと組み合わせて使える，ABテストを実施するためのフレームワークがあるとして，社内のプロダクトは基本的にRailsを使っているので，どのアプリケーションでもABテストを簡単に実施できる，とか．
