ぼくがかんがえた最強のマイクロサービスのつくりかた。（メモ）
「マイクロサービスって、何の為に考え出したの？」というポイントを押さえずに、マイクロサービスの手法（Rest APIやDockerなど）だけを追いかけると、間違った方向に行ってしまうのでは？と考えています。
要は「何かマイクロサービス流行っているから手を出すぜー！」では無くて、「何でこういう事したいんだっけ？」という意図を想像して、「ぼくがかんがえた最強のマイクロサービス」を生み出していけばいいんじゃないのかな？という話です。
因みに、凄くざっくり書いているので、何かの刺激にったら嬉しいな。程度。
■マイクロサービスをやる動機は何か？何故マイクロサービスを利用したいのか？
まず、「なぜ、マイクロサービスは考えられたのか？」を考えるのが大事かと思います。
マイクロサービス自体はタダの手法であり、目的ではないです。
「マイクロサービスを使いたい」は目的にはなりません。
「何か到達したい目的があって、その為にマイクロサービスにします」という事です。
自分は、「ソフトウェア（コード）のあるべき姿を追求していったら、マイクロサービスに行きついた」という理解をしています。
なので、「ソフトウェアのあるべき姿」を考え、それを実現する手法として、マイクロサービスというアーキテクトをどう活用するか？という考え方のもと、「自分たちが作るマイクロサービスとは何か？」を考えるのが良いかと考えています。
■マイクロサービスとは
2014年、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが提唱したソフトウェアアーキテクチャである。
■マーチン・ファウラーとは
とりわけ
・オブジェクト指向分析とオブジェクト指向設計
・統一モデリング言語 (UML)
・アナリシスパターンをはじめとしたソフトウェアパターン
・エクストリーム・プログラミング (XP) を含むアジャイルソフトウェア開発方法論
の各分野において、活発に活動している。
マーチン・ファウラーが今まで何にこだわって来たのか？というと、「良いコードを書く」事にこだわってきた。
■「良いコード」とは何か？
「良いコード」とは、生産性の高いコードだと思っています。
これは、開発期間の生産性ではありません。EndOfLifeを迎えるまでの期間を指しています。
なので、決して作り易さではないです。
何故なら、作るよりも保守の方が時間が長いので、トータルで考えると、「保守性、再利用性、カスタマイズ性」を高める事が、生産性向上になります。
■良いコードを書くためのヒント
コンパイラが理解できるコードは誰にでも書ける。
すぐれたプログラマは、人間にとってわかりやすいコードを書く。
■プリンシプル・オブ・プログラミング
・変更容易性
・相互運用性
・効率性
・信頼性
・テスト容易性
・再利用性
■実装パターン
・結果の局所化
・繰り返しの最小化
・ロジックとデータの一体化
・対称性
・変更頻度
■リファクタリング
■原則
・KISS（KeepItSmallAndSimple)
・DRY（Don't Repeat Yourself）
・YAGNI（You Aren't Going to Need it）
・PIE（Program Intently and Expressively）
・SLAP（Single Level of Abstraction Principle）
■「良いコード」を作る為にはどう設計（アプローチ）したら良いの？
これの一つの解が、「ドメイン駆動設計」だと考えている。
ドメイン駆動設計：顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法
■結論
「良いコード」→「良い部品」→「良いシステム」にこだわっていき、それの単位を「マイクロサービス」として提供する。
■参考
余程の理由がない限り記事は無料です。読まれた方が何かしら刺激を受け、そして次の良いものが生まれてくれると嬉しいです。