Skip to content

DNET_ArchitectureAstronaut

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

アーキテクチャ宇宙飛行士

概要

Excel Basicの設計とマイクロソフトのVBA戦略を推進した、
「ジョエル・スポルスキ」によると、
アーキテクチャ宇宙飛行士は、

抽象的に言えば、

  • 地球から、あまりにも遠くに行ってしまった頭の良い人で、
  • いつ停止するのか分からない、酸素が足りなくなっている人。
  • 包括的で高レベルだが、不条理な「宇宙から見た地球の写真」を作成する。

などと、表現されている。

詳細

傾向

  • 収益に貢献しない非常に高度な学位を持った
    多くの非生産的な人々を雇う余裕がある大企業で働く傾向がある。
    （コレは、シェアが大きいから出来る事だと言えるかもしれない）

  • 彼らは、アーキテクチャについて考えることをやめないので、
    彼らに、コードを書いたり、プログラムを設計させるのは非常に難しい。

実際の問題は解決していない。

  • アーキテクチャ以外の「機能」の話はすべて無視する。

  • 新しいアーキテクチャを発明し、
    それが「何か」を解決すると主張する。

  • 「解決できたら役に立つ」実際の問題ではなく、

「（そのアーキテクチャが）解決できる（と考えている）」存在しない問題

を解決している（ダケに過ぎ無い）。

※ 例えば、SOA化すると、差し替えが可能になるが、実際に、
　 その「差し替え」を行うケースが以下ほど在るのか？と言うような話。

確かに利益をもたらすが誇大。

  • 例えば、

    • 生産性・保守性の向上
    • 「参照アーキテクチャ」（モデル）として整理されている。
    • 考慮点が減る（ブラック・ボックス化）。

  • しかし、誇大広告に問題があることもある。

  • そして、何故か人々は、
    その退屈なアーキテクチャに「非常に」感銘を受ける。

    • RPCの新しいフォーマット
    • または単なる新しい仮想マシン

事例

  • P2P、Java, XML, Soap, XmlRpc（, Hailstorm）, .NET, Jiniなど。

  • 以下のような技術が、該当すると考えるが、全てが非機能であって、
    「異なるアーキテクチャでも機能要件を満たせる。」という傾向を見い出せる。

  • 宗教戦争、宗教対立的な雰囲気（OS、言語、設計技法、フレームワークなど）

設計・実装系

  • オブジェクト指向の分析・設計（OOA、OOD）
    この辺（なんとか原則の該当節を参照）が
    「まぁ、解る。」位に留めておくと良い。

  • ドメイン駆動設計（DDD）

    • 高位の概念と実践について多数述べられている。
    • クリーン・アーキテクチャ（依存性反転原則の該当節を参照）
      （は、比較的、実践的かも）

ネットワーク系

この辺（その他、開発の色々の該当節を参照）の技術で、
前述の「RPCの新しいフォーマット」的なもの。

  • 分散オブジェクト（DCOM、CORBA）
  • REST、JSON-RPC、OpenAPIとSwagger
  • SOAP、SOA（Service-Oriented Architecture）
  • Microservice & Serverless Architecture

テスト自動化系

この辺（テスト自動化）にまとめた系

  • TDDや、GUIテストツール

  • DevOps（CI/CD）（サービスの該当節を参照）と
    絡めたIaC、Open PaaS

ユーザインタフェースとデータアクセス系

この辺（VS系コンテンツ）に書いたように、ほぼ、トレードオフ。

  • ユーザインタフェース

    • フロントエンド系全般

  • データアクセス

    • O/R マッパー

この新しい開発言語は生産性が高い！的な。

TIOBE Index（シェアの該当節を参照）でも眺めてろ！

  • Java / .NET
  • Java の成功体験を Ruby で。
  • JavaScript / ECMAScript
  • Python / R（アール）

私見

なんとなく、

目の前の問題の解決に"注力"すベキ。

「参照アーキテクチャ」（モデル）に準拠して開発されたプロダクトが
その結果、結果的に、「何か」を解決するか？に"注力"すベキではない。

基礎と応用力を強化すベキ。

  • 当該アーキテクチャは複数の基礎を組合せた応用と見る事が出来る事が多そう。

  • 従って、基礎が出来ていれば応用できるので、基礎（と応用力）を強化すベキ。

  • 「参照アーキテクチャ」（モデル）は複数の基礎を組合せた応用結果
    （基礎のリレーション）を明示している。

  • 基礎と応用力があれば、要件に適合した「参照アーキテクチャ」（モデル）を
    理解する事、構築する事が出来る。

  • 「参照アーキテクチャ」（モデル）が合う合わないの意思決定～を
    変形させる能力が無いと、案件にフィットした設計ができない。

と言う事かと思う。

参考

ジョエル・スポルスキ - Wikipedia

https://ja.wikipedia.org/wiki/ジョエル・スポルスキ

OSSコンソーシアム

マイクロソフト系技術情報 Wiki

  • アーキテクチャ設計
    • アプリケーション・アーキテクチャ
    • プラットフォーム・アーキテクチャ
    • クラウド (Azure) アーキテクチャ
      • テクノロジ
      • クラウド設計パターン
      • アーキテクチャ フレームワーク
      • アーキテクチャ ガイド
      • 参照アーキテクチャ、
        ワークロードの例、
        ソリューションのアイデア

開発基盤部会 Blog

Tags: 移行, アーキテクチャ, 技術, 生産技術, 開発基盤

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally