MS萩原さんのセッション。同名の書籍（元ネタはDBマガジンの同名の連載）が元になっていて、そのダイジェスト版＋最新の動向の補足、という形。
とても示唆に富んでいるんだけど、抽象的な上に、1つ1つのトピックがめちゃめちゃ重たいので、きちんと理解しようとすると調べる量がとても多くなってしまう上に、そもそも理解しきるのが難しすぎる。とりあえずは現段階の自分の稚拙な理解をもとに、こんなことじゃないかなーと補足しながら書いていく。
アーキテクチャの原則
アーキテクトにとっては、アーキテクチャの原則を理解することが重要。アーキテクチャの原則は、インフラなどが変化しても変わらず、クラウドでも通用する。
アーキテクチャ先行定義の原則
アーキテクチャは先行定義せねばならぬ、という原則。アーキテクチャ設計を含むソフトウェア開発は、こんな風な流れになるはず。
モデリングとアーキテクチャ設計の双方のインプットとして、システムの機能要求・非機能要求があげられていた。
■ モデリング
この部分は、システム化対象（ドメイン）を何らかのパラダイム（DOA/OOAなど）でモデル化する作業だと思われる。ドメインモデリングであれば、主に機能要件がそのインプットとなりそうだ。
■ アーキテクチャ設計
アーキテクチャパターンやリファレンスモデルをもとに、機能/非機能要件を満たしうるアーキテクチャを整備していく作業だと思われる。アーキテクチャ設計では、例として以下のような項目を（仮）決めしていくようだ。
# メモしきれなかったので一部のみ ^^;
- プラットフォーム
- フレームワーク
- データモデル
- トランザクションモデル
- セキュリティ
[メモ]
図では、モデリングとアーキテクチャ設計が並列になっているが、モデリングとアーキテクチャ設計を完全に独立で実施できるとは思えない。アーキテクチャ設計にフレームワークやデータモデルが入っていることから、お互いになんらかの関係があることを示唆している気もする。もしかしたら、順序関係や依存関係を定義した図ではないのかもしれないし、マッピング/設計のフェーズがそれを包含しているのかもしれないが、セッションからはよくわからなかった。
個人的にここで重要だと思うのは、システム開発にはなんらかの形での「システム化対象のモデリング」が存在することを明示している点。そして、DOAやOOAを包含して「モデリング」としている点。データモデリングやオブジェクト指向モデリングをしているんじゃなく、「システム化対象」を「データの観点」や「オブジェクトの観点」からモデリングしているんだ、というのは、個人的になんだかしっくりくる。
[/メモ]
[/メモ]
データアーキテクチャの原則
データには、マスターデータとトランザクションデータが存在するが、それぞれのデータには特性があり、扱う方法にも原則がある、という話。
■ マスターデータ
- 複数のアプリケーションで共通的に使われるデータ
- 論理的にはアプリケーションの外に出すのが原則
■ トランザクションデータ
- 属性として「時間」を持っている
- 追加（新規作成）のみで、変更も削除もされない
- ETLなどでDWHやDMにぶちこまれる
# なんかこんな感じだった気がする。
実際は、特にマスターデータに関してはこのようになっていないことが多い。これは、マスターデータ自体の共通性は高いのだが、ビューが異なると必要な属性が異なってくる（属性にバリエーションがある）ため、Factor outしづらいのが原因。
なお、マスターデータは論理的に一箇所で管理すればよく、必ずしも物理的に一箇所で管理する必要はない。
[メモ]
- マスター、トランザクションの区分はデータモデリングの王道中の王道。THでもTMでも、定義の厳密性や名前の違い（イベント/リソースなど）こそあれ、基本的なスタンスは同じ。
- マスターデータをアプリケーションにまたがって共通的に持つ、というのは、最近DOA界隈（と言ってしまっていいのだろうか）ではやりのMDM（Master Data Management）と同じですね。データ総研の椿さんも同じこと言ってました。
- マスターデータがコンテキストごとに属性のバリエーションを持つ、という問題を解決する方法は明示されなかった気がするんだけど、どのように考えているんだろうか？「外だしする＝共通性として認識する」、「コンテキスト（アプリケーションやビュー）ごとに持つ＝可変性として認識する」と考えると、結局は共通性と可変性の認識の問題になる気がする。負の可変性とか。この境界は、時間の経過や事業領域の変更でも変わっていくのだと思われる。
- 物理的に一箇所にする（大福帳DB？）のではなく、論理的に一箇所にすれば良い、というのは現実を考えると非常に重要だと思う。
[/メモ]
Entity（個体）識別の問題
Entityはそれ単独（そのものが持つ本質的な特性）では決まらず、他との相対的な関係でしか決定できない。Relationshipは関数従属性であり、ビジネスから決まる、とも言っていた。
[メモ]
これは、データモデリング（OOも）の永遠の課題である、個体（Entity）をどうやって認識するのか、という話だと思うが、CoddのRelationalモデルとChecnのEntity-RelationshipモデルはどちらもEntityの識別方法を与えてくれない。詳しくは忘れてしまったけど、そもそもRelationalModelにはEntityなんてなかったと思うし。ChenのE-Rモデルでは、Eのまともな定義がないため、抽出の役に立たない。
TMとTH、両方のセミナーを受けたことがあるんだけど、ChenのERモデルが工学的（実務的？）に問題があることまでは共通の認識として持っていて、それぞれに定義を補足した上で抽出手順を決めている。詳しくはそれぞれのモデリング技法をどぞ！
追記：
書籍の方では、データモデリングにおいては既存の帳票や画面からのボトムアップ＋関数従属性による正規化によって、Entityは一意に識別できる。が、OOの場合はトップダウンにならざるを得ず、一意性を保証できない点が問題だ、という感じで書いてあった。
追記：
書籍の方では、データモデリングにおいては既存の帳票や画面からのボトムアップ＋関数従属性による正規化によって、Entityは一意に識別できる。が、OOの場合はトップダウンにならざるを得ず、一意性を保証できない点が問題だ、という感じで書いてあった。
[/メモ]
アプリケーションの設計モデルは、データモデルと独立して定義可能。ビジネスモデルをそのまま反映することもできる。アプリケーション設計モデルのコアな部分は、ユースケースと独立して、先行して定義する。関係はユースケースが決まらないと確定しないので、ブレが大きくなる。
[メモ]
「アプリケーション設計モデル」が少しわかりづらいんだけど、自分はアプリケーションの構造（特に、PoEAAのDomain Logic Patternsに相当するもの）の選択と、それがドメインごとに具体化されたものだと理解した。そうすると、Domain Logicのモデルはデータモデルとはある程度独立になる話も理解できるし、アプリケーション設計モデルのコアがUCの定義に先立つ、という話も、勘定構造（Accounting Patterns）の導入などと絡めて考えれば理解しやすい。気がする。
[/メモ]
縦の構造と横の構造
アプリケーションの構造は、縦の構造（Entity）と横の構造（Relationship）から成ると考えることができる。縦の構造は比較的固定化されており、横の構造は比較的流動的。変更要求があった際に、それが縦の構造に影響を与えるか、横の構造に影響を与えるかによって、修正コストは大幅に違ってくる。
# よって、（このコンテキストでは）いかにEntityを安定なものにするかが重要になってくる。
[メモ]
この「縦の構造」と「横の構造」は、ソフトウェア（ひいてはビジネス）は視点によって複数の構造を取りうることを表している。
ただ、モデルとしては複数の構造を持っていたとしても、複数の構造をソフトウェアとして実装するのは単一のパラダイムでは難しい。
手続き型では階層的に詳細化された手続きを呼び出すような単純な構成になるし、オブジェクト指向であってもクラス構造は基本的に単一で、まったく違うクラス構造を重ね合わせて実装することはできない（多重継承やMix-inはある程度これを可能にするが）。
複数のパラダイムが形作る構造が対等な関係で関連し合うようなアーキテクチャも考えられるのかもしれないが、現段階では主たるパラダイムが主たる構造を構成し、それ以外のパラダイム（やメカニズム）が補足的な構造を形作ることが多い。この、主たる構造が縦の構造、補足的な構造が横の構造と呼ばれているのかなーと感じた。
補足的な構造を導入するためのパラダイムがアスペクト指向で、現状では主としてアスペクト指向プログラミングが、（ビジネス構造を表す主たるクラス構造に）非機能要求の実現を表す構造を導入する形で用いられている。ヤコブソンは、アスペクト指向による分析・設計を考えており、ユースケース（というアスペクト）を分析・設計段階で扱うことを考えているようだが…。
ただ、モデルとしては複数の構造を持っていたとしても、複数の構造をソフトウェアとして実装するのは単一のパラダイムでは難しい。
手続き型では階層的に詳細化された手続きを呼び出すような単純な構成になるし、オブジェクト指向であってもクラス構造は基本的に単一で、まったく違うクラス構造を重ね合わせて実装することはできない（多重継承やMix-inはある程度これを可能にするが）。
複数のパラダイムが形作る構造が対等な関係で関連し合うようなアーキテクチャも考えられるのかもしれないが、現段階では主たるパラダイムが主たる構造を構成し、それ以外のパラダイム（やメカニズム）が補足的な構造を形作ることが多い。この、主たる構造が縦の構造、補足的な構造が横の構造と呼ばれているのかなーと感じた。
補足的な構造を導入するためのパラダイムがアスペクト指向で、現状では主としてアスペクト指向プログラミングが、（ビジネス構造を表す主たるクラス構造に）非機能要求の実現を表す構造を導入する形で用いられている。ヤコブソンは、アスペクト指向による分析・設計を考えており、ユースケース（というアスペクト）を分析・設計段階で扱うことを考えているようだが…。
[/メモ]
パラダイムの進化
オブジェクト指向には限界がある。
- 言語間の通信が困難
- 動的なオブジェクトのブートやシャットダウン
- 非機能の扱いが困難
[メモ]
言語間の通信とか、OOの問題ではなく、OOの典型的なプラットフォームが持つ問題のような気がするんだけど…。動的なオブジェクトのブートやシャットダウンも同じく。
[/メモ]
パラダイムは進化してきた。
手続き型 => オブジェクト指向 => コンポーネント指向 => サービス指向 => Web指向
[メモ]
コンポーネント指向は、言語間の通信が困難である点を解消する。サービス指向が改善するものはなんだろう？再利用可能性だろうか？
Web指向というのは聞いたことがなかったんだけど、分散化され、メッシュ上にリンクされたリソースをコードが扱う、というモデルらしい。
[/メモ]
これらの進化は、古いものを置き換えてきたというわけではない点が重要。新たに登場したパラダイムでの開発には、以前にパラダイムも必要になる。組み合わせて使うことが必要。
[メモ]
フレームワークやミドルウェアの登場で開発はどんどん簡単になっているはずなのに、なぜか難しく感じる理由は、これである程度説明できるのかもしれない。抽象の破れとあわせて説明すれば、直接開発に関わらない人が「うまく開発することが、なぜいまだに難しいのか」を理解する助けになるだろうか。
[/メモ]
モデルをどう作るか？
システムはさまざまな視点からのモデル化することになるが、どのようにすればうまく表現できるのか？
# モデルの話再び。個人的にはここが最重要トピック。
問題をうまく分類し、分割することが重要。単一のパラダイムではうまく対応できないため、マルチパラダイムで対応する。これから、いくつかのパラダイムとその問題点を見ていく。
■ オブジェクト指向
クラス決定に一意性がなく、属人的であることが問題とみなされる。このせいで、手続き指向への回帰が起こっているケースが多々見られる。
（個別UCの）要求によってクラスの構造を変えてはならない。要求の実現ではなく、保守性を目的としてクラス構造を取る。
OOには多くの制約があり、これを乗り越える・補完するためにさまざまなパラダイムが考案・導入されつつある。
■ アスペクト指向
可変性にフォーカスした技術。メモで前述。このあたりから全部、ものすごいさらっと紹介していく流れに。
可変性にフォーカスした技術。メモで前述。このあたりから全部、ものすごいさらっと紹介していく流れに。
[メモ]
可変性というのは、ドメイン工学やマルチパラダイムデザインの用語で、システム・もしくは概念の変わりうる部分のこと。AOPが可変性にフォーカスした技術である、ということは、システムの変わりうる部分をアスペクトとして実装することが意図されている、ということだろうか。あまりそんな風に使ってないような気がするが。
ユースケースをアスペクトとして扱うのであれば、この言説に合致するんだけど、あってるのだろうか。
[/メモ]
可変性というのは、ドメイン工学やマルチパラダイムデザインの用語で、システム・もしくは概念の変わりうる部分のこと。AOPが可変性にフォーカスした技術である、ということは、システムの変わりうる部分をアスペクトとして実装することが意図されている、ということだろうか。あまりそんな風に使ってないような気がするが。
ユースケースをアスペクトとして扱うのであれば、この言説に合致するんだけど、あってるのだろうか。
[/メモ]
■ サブジェクト指向（Subject Oriented）
再利用にフォーカスした技術らしい。こちらもさらっとした紹介程度で終了。
[メモ]
どんなものかもわからないので、Webで調べてみた。
サブジェクト指向プログラミング（Wikipedia英語版）：
なんのこっちゃ。雰囲気からすると、オブジェクト指向システムをクラスとは別の構造（サブジェクト）に分解し、サブジェクトを組み合わせることでオブジェクト指向システムを構築する、というコンセプトらしい。これも、補完的な構造（横の構造）を導入するためのパラダイムのようだ。
Hyper/J：
IBMによる、サブジェクト指向開発環境のJava実装らしい。暇があれば使ってみようかな。
DCIA：
講演の中で出てきた、サブジェクト指向アプローチか製品のようだけど、調べてもよくわからなかった。
[/メモ]
再利用にフォーカスした技術らしい。こちらもさらっとした紹介程度で終了。
[メモ]
どんなものかもわからないので、Webで調べてみた。
サブジェクト指向プログラミング（Wikipedia英語版）：
サブジェクト指向プログラミングは、下記をサポートするようなプログラミング手法を指す。サブジェクトの組み合わせがもたらす柔軟性によって、OOプログラムの開発やモジュール化に新たな機会がもたらされる。
- サブジェクトの組み合わせによるオブジェクト指向システムの構築
- システムの、既存サブジェクトおよび新規サブジェクトの組み合わせによる拡張
- サブジェクトの組み合わせによる、システムの統合
広義のサブジェクト指向は、システムのサブジェクトへの分割や、サブジェクトを正確に組み合わせるためのルールの記述を含む。サブジェクト指向はOOPを補完し、以下のような問題を解決する。SOPは、サブジェクトを作る事で、プログラマの認知能力にまつわる問題も解決しようとしている。サブジェクトはその出自からして、アスペクトと大きくは違わない。アスペクトは初期に、主としてコンパイルタイムに先立ってソースを組み立てるようなコードウィーバーのコンセプトに労力を向けていたが、SOPパラダイムはクラスの組み立てに多くを依存している。
- OOPが大規模システム開発に用いられた際に発生する問題
- OOPが、相互運用可能または統合されたアプリケーションスイート開発に用いられた際に発生する問題
なんのこっちゃ。雰囲気からすると、オブジェクト指向システムをクラスとは別の構造（サブジェクト）に分解し、サブジェクトを組み合わせることでオブジェクト指向システムを構築する、というコンセプトらしい。これも、補完的な構造（横の構造）を導入するためのパラダイムのようだ。
Hyper/J：
IBMによる、サブジェクト指向開発環境のJava実装らしい。暇があれば使ってみようかな。
DCIA：
講演の中で出てきた、サブジェクト指向アプローチか製品のようだけど、調べてもよくわからなかった。
[/メモ]
ビジネスのモデルをそのままソフトウェアクラスの構造に反映する。ユースケースの要求はサービスとして実現することで、ビジネスのモデルを安定にできる。
[メモ]
DDDによる本来のサービスの定義は、ビジネスで認知されている純粋な手続きや、複数のドメインクラス（Entity/ValueObjet）にまたがる処理をサービスに記述することになっている。
結果的にユースケース要求がサービスに実装されることになることもあるかもしれないが、本来のDDDの意図とは少し違っているように思える。DDD本で紹介されている本でも、ユースケースによって徐々にドメインクラスを変更していっているしなぁ。このあたりはできれば直接質問したかったんだけど、できずじまい。
[/メモ]
[メモ]
DDDによる本来のサービスの定義は、ビジネスで認知されている純粋な手続きや、複数のドメインクラス（Entity/ValueObjet）にまたがる処理をサービスに記述することになっている。
結果的にユースケース要求がサービスに実装されることになることもあるかもしれないが、本来のDDDの意図とは少し違っているように思える。DDD本で紹介されている本でも、ユースケースによって徐々にドメインクラスを変更していっているしなぁ。このあたりはできれば直接質問したかったんだけど、できずじまい。
[/メモ]
■ フィーチャ指向
可変点をフィーチャとして分析する。フィーチャ指向は、静的・コンパイル時バインディングが基本だが、これを動的にバインドできるようにしたものとして、コンテキスト指向というものがある。
かなりさらっとした紹介で終了。もう少し掘り下げて調べてみようと思ったけど、それはそれで膨大になりそうなので今回は省略。それにしても、フィーチャ指向のフィーチャって可変点だけだっただろうか？システム自体を概念とフィーチャで分析していく手法で、フィーチャの分析として可変かどうかを調べていたような記憶があるんだけど、間違っているかもしれない…。
■ セル生産方式
プロセスの抽象化と再利用らしい。さらっと終了シリーズ。
[メモ]
セル生産方式の解決する問題が、プロセスの再利用だとは知らなかった。簡単にしか紹介されなかったので、詳しいことはわからずじまい。書籍に期待。
プロセスの抽象化と再利用らしい。さらっと終了シリーズ。
[メモ]
セル生産方式の解決する問題が、プロセスの再利用だとは知らなかった。簡単にしか紹介されなかったので、詳しいことはわからずじまい。書籍に期待。
[/メモ]
■ 関数型パラダイム
すべてが関数。クラウドの普及によって、中〜長期的には重要になってくるはず。
■ 関数型パラダイム
すべてが関数。クラウドの普及によって、中〜長期的には重要になってくるはず。
以上紹介してきたように、パラダイムは多数存在しているが、いずれにしろドメインに特化したパラダイムを選ぶのが重要。
妥協のない意思決定の方法
目的－手段の階層を意識するのが重要。手段のレベルでトレードオフが発生した場合には、同じレベルでは選択できない。目的−手段階層をさかのぼり、上位の階層でトレードオフを解消できないか（まったく別の手段を取る事ができないか、目的レベルで考えると手段の1つは不要になるのでは、などなど）を考えることで、妥協せずに意思決定することができる。
[メモ]
これ重要っすよね。事業戦略もまったく同じで、経営レベルから自分へいたる意思決定のパスが明示されていないと、現場レベルでは判断つかないことが多い。
[/メモ]
萩原さんの夢とメッセージ
プログラミングやインフラなどの実装に近い部分や、ビジネスや要求よりの部分は注目され、色んなことが試されているが、その間の設計の部分は意外と注目されておらず、軽視されているとも言える。ここにはまだまだ向上の可能性があるので、ここをきちんとやっていくということを夢として持っている。
みなさんへのメッセージとしては、ユニーク性を持つ、ということをすすめたい。ユニーク性のない仕事は、どんどん代替可能な人材に置き換えられ、価値も下がってしまう。ユニーク性を持てば代替は不可能となり、価値を発揮できる。ぜひユニーク性を持ってください。
雑感
個人的には、一番ストライクゾーンに近かったセッション。ここ1年ほど興味を持って調べていた内容に非常に近く、自分の考えを確認しつつ新たな試みに触れることができた。もちろん、より良い整理のヒントも得ることができた。
内容は全体に浅く広くだったとはいえ、モノの見方を紹介するという意味ではどんな人にとっても刺激になるセッションだったんじゃないだろうか。書籍「アーキテクトの審美眼」も発注したので、届いたら改めて深く掘り下げてみたい。
目次：
QCon Tokyo 2009に行ってきた
雑感
個人的には、一番ストライクゾーンに近かったセッション。ここ1年ほど興味を持って調べていた内容に非常に近く、自分の考えを確認しつつ新たな試みに触れることができた。もちろん、より良い整理のヒントも得ることができた。
内容は全体に浅く広くだったとはいえ、モノの見方を紹介するという意味ではどんな人にとっても刺激になるセッションだったんじゃないだろうか。書籍「アーキテクトの審美眼」も発注したので、届いたら改めて深く掘り下げてみたい。
目次：
QCon Tokyo 2009に行ってきた
コメント