SOAとマイクロサービスを複合設計に当てはめると見えるもの
ざっくりと物事を考えると、案外見えてくる事もあるものです。細かな事は置いておいて、「昔は〇〇というのがあってな、、」と昭和のジジイらしく考えてみました。
SOA(Service-Oriented Architecture)
SOAを知ったとき、サービスの考え方がトランザクション分割の様だと思いました。
トランザクション分割というのは機能中心の設計法である複合設計で紹介されているプログラム分割法です。構造化設計の文献でご存じの方もあるでしょう。
複合設計でプログラムを分割する際は、上位モジュールはトランザクション毎にモジュールを分割し、下位モジュールは 共通機能分割・データ構造分割します。そして、中間のモジュールは源泉・変換・吸収型分割(以下STS分割)します。
SOAと言われ出した頃は、プロトコルが話題になりましたが、その実はサービスという大きな機能の単位でAPIを作りましょうということなので、トランザクション分割とさほど変わらない様に感じたのです。
マイクロサービス
最近はマイクロサービスという言葉が騒がれ出しています。汎用的な小さなサービスを用意しておけば、それらを組み合わせてシステムをつくれ、保守も容易でウハウハ!といった話を聞くと、複合設計の共通機能分割やデータ構造分割を思い出します。
複合設計で考えると、トランザクション分割はトップダウンですが、共通機能分割やデータ構造分割はボトムアップなので、汎用性の高いモジュールを実現できます。しかし、それだけではシステムを構成できないので間をつなぐ必要がありました。
構造化分析/設計ではDFDの中心を引っ張り上げてプログラム構造を作るという手法がありましたが、無理矢理なインタフェースでは良いプログラムはできませんでした。複合設計では最も抽象的はデータのところをインタフェースにするというSTS分割で、上のような中間をつないで少しマシな構造を実現しました。
構造化分析/設計にしろ複合設計にしろそれなりに動くのですが、保守性が悪く、その後のオブジェクト指向やデザインパターン、ソフトウェアアーキテクチャなどの議論に繋がりました。
歴史は繰り返す
そのように考えていると、変な感じがしました。SOAにしろ、マイクロサービスにしろ、オブジェクト指向の人たちが言い出していたからです。
技術は壁にぶつかった時、新しい解決法を生みます。それまでのオブジェクト指向が壁にぶつかった時、新しい解決法としてかつてライバルとした仕組みを取り入れて、新しいオブジェクト指向に生まれ変わろうとしているのでしょう。
たぶん、マイクロサービスだけではうまくいかないと思います。マイクロサービスをどのようにまとめるか、どのようなアーキテクチャーを実現するかなど、経験を蓄積すべきなのでしょうね。
今は問題を洗い出している段階なので、色々と工夫が必要なのだと思います。やがて、方法論やパターンがでてきて、設計で行われたように、問題の解決と問題領域の変更を繰り返すと思います。
気になるのは、エージェントがいつ再登場するか、機会学習の普及で潮目が変わるのかですが、どうなるのでしょうね。
« ソフトウェア産業に望まれる人材 - 情報の波に飲み込まれないには - | トップページ | マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで - »
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。

コメント