たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

「伝票指向アーキテクチャー」を知っていますか?

(※この記事は2015年に書いてて放置してたのですが、今さら公開してみます。)
 
浅海智晴氏のRelaxer、そして「伝票指向アーキテクチャー」を覚えているでしょうか?知っているでしょうか?氏のブログを読ませていただいてる間に下記記事のことを思い出しました。
 
@IT、「Relaxerで実現するJava開発の新プロセス」-「3.1 伝票指向アーキテクチャ」:
 
この記事は2003年のものですね。(今でも残っていました!)まずはさくっと読んでみてください。
 
最も重要な部分を引用(キャプチャー)させていただきます。
 

 
この図9の右側の「データ流通モデル」は伝票指向アーキテクチャーの中核的概念を表していますが、これは今で言うマイクロサービス(Microservice)の構造そのものです。当時として伝票指向アーキテクチャーはXMLセントリックであることが強調されていますが、その点は除いてコンセプトのエッセンスに注視しましょう。二つのコンポーネントそれぞれがマイクロサービスに相当しますね。データベースは共有しておらず、二つのデータベースの一貫性は、伝票のやりとりによる結果整合性(Eventually Consistency)で実現される訳です。記事では「結果整合性」という用語こそ用いられてはいませんが、データの「共有」ではなく「流通」としてその概念に迫っています。記事中では「伝票指向アーキテクチャー」の理由、意味、利点等が次のように解説されています。
 
相性の良さは、ビジネスアプリケーションが本質的に元帳と伝票を操作する処理を行うものであることによる。・・・(略)・・・元帳と伝票の操作に特化されたCOBOLの言語仕様が、本質的に重要だったことを物語っている。
 
コンポーネント指向では、データをコンポーネント内にカプセル化し、データの流通は共有データではなく、コンポーネント間を流通するデータを通して行われる方法が基本になると考えられる。
 
現代のコンポーネント指向では、分散コンポーネントが基本となる点も重要だ。
 
これらの説明は、そっくりそのままマイクロサービスの理由、意味、利点の説明として読むことができます。
 
◆以上