コンビニ弁当の空き容器が部屋に放置されがちで、それは端的に言うと自分がズボラなだけなのだけれど（Q.E.D.）、どうしてこうなってしまうのかということを考えていた。すると意外なところに答えがあった。
最近自分は『モノリスからマイクロサービスへ』を読んでいる。まだ途中までしか読んでいないが、この本によれば、マイクロサービスをただ一つの表現にまとめるならば、それぞれが独立した単位でデプロイできるようにすることがマイクロサービスである。
この原則の重要性には実体験でも心当たりがある。先日やっていたプロジェクトでは、各コンポーネントが勝手にデプロイできるようにうまくアーキテクチャを組んでおいたおかげで、手詰まり状態になることを回避できていたのだ。
ライフサイクルの異なるコンポーネントを密結合にして1つのデプロイ単位に押し込んでしまうと、多くの場合非効率的な状態に陥ってしまう。例えば機械学習を扱うコンポーネントとフロントエンドコンポーネント、そしてバッチ処理を扱うコンポーネントがあるとすると、それらのライフサイクルはバラバラだ。おそらくフロントエンドコンポーネントは臨機応変に変更されるだろうし、機械学習コンポーネントは定期的な再評価と更新が行われるだろうし、バッチ処理はバッチ処理自体に変更があるまで再デプロイされないだろう。これらを一緒くたにして密結合な状態にしておくと、頻繁に変更される一部のコンポーネントによって、本来は変更しなくても良いコンポーネントに変更が波及してしまい、そのたびに修正を余儀なくされるという状況が常態化してしまう。どこかをいじると壊れるシステムの完成だ。
これをコンビニ弁当に置き換えると、自分は以下のような状態に陥っていることがわかる:
- コンビニ弁当を買ってステンレススプーンや自前の箸で食べる。
- コンビニ弁当の空容器が発生する。このコンポーネントは破棄しなければならない。
- 使用後のステンレススプーンや箸は破棄してはならず、再利用するために食洗機に送らなければならない。
- 空容器を捨てるにはいったん食洗機が空いてカトラリーを洗える状況を待たなければならない。
- カトラリーを洗うにいったんはゴミ箱が利用可能で空容器を捨てられる状況を待たなければならない。
- すなわち、ライフサイクルが異なるコンポーネントが一時的結合状態にある。
この状況を解消するには、コンポーネントを分離するべきだが、コンビニ弁当はカトラリーがなければ食べることができず、カトラリー単体では餓死を防ぐことができないため、別の方策を考える必要がある。それは、カトラリーを使い捨てに切り替えて強制的にライフサイクルを合致させることである。
- コンビニ弁当を買って使い捨てスプーンや割り箸で食べる。
- コンビニ弁当の空容器と使用済み使い捨てスプーン・割り箸が発生する。このコンポーネントは破棄しなければならない。
- ゴミ箱が利用可能であれば、全てのコンポーネントを一気に捨てることができる。
- 全てのコンポーネントのライフサイクルが合致している。
もちろん、スーパーで買ってきたものなどを食べるときは最初から陶器の皿やステンレスのカトラリーを利用することができる。これは調理のライフサイクルと食事のライフサイクルが隔離されており、前後関係を除けば互いに影響しないためである。
- スーパーで買った素材を元に料理を作成する。
- 料理によって発生した廃棄物を捨てる。
- 盛り付けられた料理を食べる。
- カトラリーを食洗機に送る。
これはドメイン駆動開発における境界付けられたコンテキストの一例である（こじつけ）。
まとめ
ちゃんと料理しろ
他方、コンビニ弁当は環境構築が不要なサーバレスであり、セブンイレブンクラウドによって無限にスケールする。
