日々の破片

_ マイクロサービスアーキテクチャを購入

昨晩は池袋ジュンク堂で高橋さんの2017年版このコンピュータ書がすごいに参加。

いろいろ買ったが（やはりドンカルロス スペインの皇子は無いな）、コンピュータ書では取り上げられていたマイクロサービスアーキテクチャを購入。

この2〜3年ほど、いつの間にか作られていた野生のマイクロサービス相手にいろいろ手直ししてきたが、あまりのひどさにここ数ヶ月で新規に設計し直して実装し直している。

おれの設計はどう考えても理に適っているし正しいが（必ずしも美しくはない）、そうはいっても世の中の趨勢とかけ離れているような見識や業界の狭さに起因する設計バグがあるかも知れないな、と考えたからだ。

そもそも野生でそのへんをうろついているくらいに、マイクロサービスは、分散システムではむしろ自然な実装形態となる。

問題は、依存性（実行時のDIとかだけではなく、設計レベル、仕様レベルでもあるし、配布レベルでもある）の解決と、状態の管理だ。

状態の管理からはセントラルコンテキスト方式が最適なのではないかと考えるが、他にも賢くて効率が良くかつ安全な方策が考案されているかも知れない。

依存性を減らすには、サービスの層を薄くするのが肝要ではないかと考えているが（野生のゴミクズは、何も考えずにモデルという名前のデータ転送オブジェクト、無意味に複雑なデータアクセス層、名前だけはリソースとなっている外部インターフェイス層の、典型的なばかの1つ覚え3層構造になっていてうんざりさせられたので、それに対するアンチこそが正しいと結論づけたからだ）、もしかすると異なる賢明な多層構造があるかも知れない。

というわけで今頃になって読んでいるのであった。

マイクロサービスアーキテクチャ(Sam Newman)

というか、前書きにも名前がついたのは最近だが、普通に作ればマイクロサービスになるよなとか書いてあって苦笑する。そりゃそうだ。

_ マイクロサービスアーキテクチャの第2章

なぜか、マイクロサービスの本だと思って読んでいると2章が、アーキテクトの役割とは？ みたいな内容で面食らう。

P.19のバグ

誤）「例えば場合」

正）「例える場合」

が、意図はわかった。

まず、再定義を行っている。

建築士ではなく、都市計画者。つまりシムシティをプレイするように進めろ。

常に変化し、市民の要求は変化し（退屈だ→野球場を作る→渋滞はごめんだ→公害をどうにかしろ）、しかし区画の中は放っておくか、環境（外部インターフェイス）を変えるかしか、手はつけられない。

で最初の時点で、フレームワークの作成者であれと書いている。

戦略目標←アーキテクチャ原則←プラクティス

の図はうまくまとまっていて参考になった。

復習とか再確認の章だ。

というか、全体がそんな感じとも言える。

悪くない。