優れたものは美しい。form follows function。
自然界に現れるフィボナッチ数列と黄金比。
エレガントな数式。
この法則はソフトウェアやITシステムにもあてはまる。
良い建築物の条件は「美しさ」「堅固さ」「快適さ」の３つであり、アーキテクチャとはこの3条件のバランスと調整であって、どれがどれを圧倒するようなことがあってもいけない。 P4元々アーキテクチャという言葉は建築を指していたけれど、ITアーキテクトという肩書きが物語るように、IT分野でも普通に使われ"仕組み" "仕掛け" "構造"といった意味合いを合わせ持っている。ITシステムにおいて、考えられていないアーキテクチャは、元々目指していた効果を得られないだけでなく、日々の運用やシステム改修において、多大なコストが発生する。それだけに、システムコンセプトというべきアーキテクチャは、熟慮の末選択されるべきである。
本書はビューティフルコードに続く、ビューティフルシリーズ第二弾で、アーキテクチャについて。ただし、企業システム全体にわたるような俯瞰・全体的なものというより、要素要素のアーキテクチャ、特にソフトウェアアーキテクチャを取り上げたものが多い。章構成は通読不要で、興味のあるところから章単位で読める形式。
目次に目を通した直後に読んだのは以下章。
第１章 アーキテクチャとは何か?
第２章 ２つのシステム：今風ソフトウェア物語
第５章 リソース思考アーキテクチャ：「web上にある」こと
第１４章 古典再読
１・２章は、本書におけるアーキテクチャの基本的捉え方が紹介される。必読。
５章では、非常に今日的な内容を扱っている。
RESTとSOAPの違いと、リソース指向アーキテクチャの考え方を解説。著者の主張は、SOAPやWSDLは「絶対NG」ではなく、「SOAPをdoc/litで使うのが有望」というスタンス。しかし、SOAPサービスではアプリケーションが求めるデータセットとは異なる、サービス提供側が設計したWSDLによってレスポンスの形式が固定され(本書内では"契約"と表現)てしまい、データの有効活用がしにくい。また特定のバインディングに縛られてしまう事で、クライアント稼働中のサービス側変更が困難になる事が問題だと主張する。
webサービススタックの主要な目的の１つは、結合度を低くし、非同期的な処理モデルを導入する事で、メッセージハンドラを新し いビジネスロジックに対応して更新でき、それでいてクライアントには影響が及ばないようにすることでした。WSDLによる束縛方式は、この目的がわかって いながら、まったく正反対の事をしたのです。 P98
SOAPは動作を起動するための優れた技術ですが、情報を管理する手段としては失敗です。RESTはまさに情報を管理しようとするためのものですが、URLを通じて任意の動作を起動するものでは必ずしもありません。 P101確かに、メソッド情報がエンベロープ内で記述され、サービス毎にラベルが異なってしまう状況下で、1)複数のSOAP/WSDL webサービスから情報を取得し、2)取得したアプリケーション内で独自のデータセットとして処理する、というケースでは指摘の通り、ごもっともと思う。
ただし、そのエンベロープやラベル自体を、サービス依存ではなく１段抽象化した上で共通的に規定したらどうか。webサービスの差異を埋めるようなもの。こうする事で、少なくともwebサービスのリクエスタ側のリクエストする部分は改修不要となるのでは、と考えたり、、、第５章は、思考が活性化されるテクスト。
３章以降１２章までの章頭に挙げられる「原理ないし特性」と「構造」の分類も、考え方の切り口として有用。
■原理ないし特性
多目的性
概念の整合性
独立に変更可能
自動伝播
構築可能性
成長対応
耐エントロピー性
■構造
モジュール
依存性
プロセス
データアクセス
そして、最後１４章は個人的な趣味とマッチする章。デザインパターン(GoF本)から始まり、 D.A.ノーマンのアフォーダンスを援用しながら「プログラム言語もそうであるべき」であると言い、暫くオブジェクト話が続いた後、突然フランク・ロイド・ライトの落水荘や、コルビジェのサヴォア邸、ミース・ファン・デル・ローエに話が飛び、最後は「建築がカオスの冒険であるというのは、それが美しいアーキテクチャだけでは不十分だからです。美しさだけでなく、有用性もが支配するという点で、建築とプログラミングは同類です。 P389」という一文で締められる。かっこいい文章です。
全章読んでいないけれど、 ここで紹介した１、２、５、１４章だけでも買う価値あります。
投稿
0 件のコメント:
コメントを投稿