解説
無謀にも・・・
まずはこの記事を読んでください(1ページ目だけで十分)
＠IT：連載：次世代開発基盤技術“Software Factories”詳解 第7回 Software Factoriesによる可変性を管理したモデル駆動型開発の例
注目するのは「可変性分析の原則」の所
可変性分析では、ソフトウェアを変化する部分と変化しない部分に分離する。両者を確実に分離することは一般的には困難であるが、以下で紹介するような、分析に有効なプラクティス（可変性分析の原則）は存在する
そして、結論
この縦（ビルディング・ブロック）と横（サービス）の関係は、安定的で変化しにくい縦と時間変化が起こりやすい横の関係ともいえる。
というわけで一番重要なのは縦と横の箱が書いてる図（ｗ
それと・・・
縦はビルディング・ブロックに閉じた変更であり比較的複雑度の低い変更である。一方、横は複数のビルディング・ブロックにまたがる変更となるので、適切な関心の分離をしてモジュール化していなければ、変更の波及範囲は大きくなりシステム変更は複雑となる。
一つのサービスを実現するために複数個のビルディングブロックが協調して動作するってことを明記してるのはとっても重要
＃この連載記事はいつもここに問題を抱えてるんだけどなぁ
で、記事の中ではサブジェクト指向により関心の分離を行うと、その結果素晴らしい「ドメインモデル」ができあがるぞと。
えっと、工程を判りやすく説明すると
- ドメインモデルの作成
- サービスの設計
- モデルにサービスを割り当て
- 最後にビルド
って事ですね。
＃ここまで間違えてないよね・・・
この記事の中ではモデルがビルディングブロックだから縦、サービスが横
そして前に出てきた記事を論理矛盾しない程度にちょっと修正
ビルディング・ブロックに閉じた変更は比較的複雑度の低い変更である。
一方、サービスは複数のビルディング・ブロックにまたがる変更となるので、適切な関心の分離をしてモジュール化していなければ、変更の波及範囲は大きくなりシステム変更は複雑となる。
間違えてないよね・・・
で、この記事の中で解決したいことは、変更の波及範囲を小さくして、システム変更をのコストを下げたいんだよね。
＃ここからぶり２の話し
ぶり２はサービスをサービスとして実装するにはどうしたらいいのか？って事について真面目に取り組んだ結果生み出されたライブラリです。
すなわち、サービスそのものをモジュール化して外から使ってもらうことであの図の横串にもビルディングブロックが登場する。
ただし、それはグラフィカルに見える化されたビルディングブロック。
そのサービスの実装にドメインモデルは必要ではなく、ERモデルみたいに単純化されたモデルでもOKになる(選択肢が増えたって事)
で、工程の所に戻ってドメインモデルの作成そのものに単純化された方法論がない状況と比較的単純化された方法論のあるERモデルを比較したとき、教育コスト他を考慮してERモデルが選択されるはず。
その結果、変更の波及範囲を小さくできかつ(初期含む)コスト的にも十分なレベルの実装が出来るはず。
っていうのがハマチ以前からまこたんの考えてて、ぶり２に繋がった話し。
＃つーかテンプレじゃないのになげーよ
