<< RDRA の神崎さんのブログ 「神崎コンサルノート」で | main | Anticorruption Layer パターン : 己を知り、敵を知れば... >>

Conformist パターン : めをつぶってアリモノを使う

「アリモノ」をうまく使えば、ソフトウェア開発は、ずいぶんと楽になる。

私たちも、Web MVC, 永続化、メッセージングなど、UI 層や、インフラ層は、オープンソースで手に入る「アリモノ」を活用している。

HTTP サーバー、メールサーバー、DBサーバー、アプリケーションサーバー、メッセージングサーバー、...、どれも、「アリモノ」を使わせてもらっている。

ドメイン層でも、「アリモノ」を使う、という選択肢は、当然ある。

上流のアプリケーションから下流のアプリケーションに情報の流れが単方向の場合、上流側の開発チームが造ったソフトウェアを、そのまま、下流でも使ってしまう、というのがConformist パターン。

When to use it : 共同作業が難しい場合


Shared Kernel パターンや、Customer/Supplier Development Teams パターンは、二つのチームが協働(コラボレート)して、お互いの Context の間の Boundary (境界)を、モデリングして、設計・実装するパターン。

共通のゴール意識(WIN-WIN)、コミュニケーションが円滑で、モデルや設計・実装の基本の考え方・やり方を共有しているのが前提。

現実には、こういう状況にないケースがたくさんある。

そういう、2つのチーム間の関係が、うまくない状況の時に検討するのが「Conformist パターン」。

細かいところには目をつぶって、上流チームが作ったソフトウェアを、そのまま使わせてもらおう、というやり方。

Shared Kenel パターンでは、二つのチームの関係は対等。

Customer/Supplier Development Teams パターンでは、二つのチームは、「顧客」役と「サプライヤ」役を演じる。(協働するけど、役割や非対称)

Conformist パターンは、「協働」しない、ということ。

上流チームが作るソフトウェアを、そのまま使って、すませる。

そのまま使って、役に立つなら、これは、有力な選択肢だと思います。
実際、現場では、多いパターンかもしれない。

メリット


相手に合わせるわけだから、余計なコミュニケーションや調整ごとは、激減しますね。

もちろん、「アリモノ」使うわけだから、モデリングと設計・実装の時間をまるごと節約できる。

上流チームのモデルと下流チームのモデルは、ばらばらに開発していても、それなりに近いモデルになっているはず。特に、お互いの Bounded Context の間にある Boundary (境界)部分のモデルは大きくずれていないはず。

これは、偶然ではなく、問題領域(ドメイン)の業務が「連動」しているなら、そこを丁寧にモデリングしていけば、「連動」のためのモデルは、上流から見ても、下流から見ても、同じになってくる。(はず)

まあ、現実には、いろいろ言いたいことも出てくるだろうけど、それなりにできている「アリモノ」を使うことのメリットは大きい。

デメリット


上流のBounded Context 担当チームには、基本的にデメリットはないですね。

下流に位置する Bounded Context の開発チームにとっては、いろいろな懸念点があります。

依存性


他のチームの開発しているソフトウェアに完全に依存することになる。
そのソフトウェアが変更された場合、もろに影響をうける。

オープンソースのソフトウェアを組み合わせて使っていれば、誰でも知っている「依存性」の問題ですね。

オープンソースの場合、後方互換性への配慮( or 非互換宣言 )、依存性の管理のやり方の工夫(ツールとリポジトリの整備)など、一昔に比べれば、ずいぶん、問題は軽減してきた。

でもアプリケーション開発の現場では、他チームの作っているソフトウェアに依存するのは、かなりかなりやっかいな問題。

Conformist パターンの場合、上流側のチームは、下流にお構いなく、ソフトウェアを変更する可能性が高いので、下流側のチームは、その影響をもろに受ける。

事前に通知とかの約束ごとを申し入れることはできるかもしれないが、「Conformist パターン」を選択する状況というのは、基本的に、先方がそういう配慮をしてくれない、というのが前提なんですよね。

10年くらい前、7-11 さん相手のシステム連携で、むこうの開発チームが NRI さんだったとき、まあ、好き勝手を言われて、やられて、えらいめに会ったなあ。

モデルの不整合、汚染


自分たちの開発しているアプリケーションの価値を最大化するために、ドメインの知識を深く掘り下げながら、初期のぎこちないバージョンを、ほんとうに役にたつソフトウェアに発展させていく。

こういうドメイン駆動設計の考え方をやろうとしたときに、その一部に他のモデルが入り込んでくることは、あきらかなデメリットですね。

アプリケーションは「入力」に大きく依存する。

「ガベッジ・イン ガベッジ・アウト(ゴミを入れたら、ゴミがでてくる)」という言葉があるように、入力情報が、アプリケーションの価値を決めてしまうことが多い。

そこそこ使える、と判断したからこそ、Conformist パターンを採用したはず。
でも、インプットになる情報のオブジェクトが、よそのチームのモデルのままだと、

・できること
・発展の方向
・変更できる範囲

などに、いろいろな制約がでてくることが多い。

良い仕事をしようと思った時に、Conformist パターンは、直感的には、「避けたい」という心理が働く。

エバンスも「Conformist パターンを使ったほうが良い状況が多いはず」だけど、現実には「あまり、選択されないパターン」だと書いていますね。

エレガントな選択肢でないことは確かです。

既存のモデルに無意識にひっぱられる


Conformist パターンについて、私が、現場で感じている、いちばんの弊害がこれ。

既存の動いているソフトウェアに、技術者はとても弱い。

「動いている=正しいモデル」と、思い込んじゃう傾向がある。

「動いていない=正しくない」は、もちろん、真実です。だからこそ、日々、バグと戦っているわけだ。

でも「動いている=正しい」では、ない。

ましてや、Conformist パターンは「人様の、よその領域」のモデルを使っているんです。

動いていても、「自分たちのモデルとして正しくない」のは、最初から明白。

モデルが違うからこそ、「 Bounded Context 」ごとに、別の開発チームで、モデリングと設計・実装をしている。

他人のモデルは、そちらの Bounded Context で有効なモデルでも、自分たちの Context には、ぴったりくるはずがない。

「正しい」モデルという表現は、まずいかな?

それぞれの Context ごとに「役に立つ」モデルは異なる。

ある Context で役に立つモデルは、別の Context では、役に立たない、ということです。

「別の Context のモデル」ということを十分に意識して参考にするなら、それは良いことです。

でも「既存のモデルにひきずられて」、自分たちが取り組むべき Bounded Context の目的・背景の理解、ドメインの知識の理解が歪むリスクには、ほんとうに注意すべき。

Conformist パターンのいちばんのリスクは、この「本来のモデル」を追いかけるという方向や、そのための努力が、汚染されっていってしまうこと。

ひとつの Bounded Context をまかされたからには、その Context で、最善のモデル、設計・実装を追及すべきなんです。

防止策・改善策


Conformist パターンを、選択した瞬間に、「特別警戒警報」発令です。

この時点で、「他のモデルに依存し、影響をうける」ことを、まず、チーム全員で再確認。
「違いがある点」を十分に理解した上で「目をつぶって」使うこと。

あとは、一日一回、「モデルの汚染度」チェックを、夕方ミーティングとかに組み込む。

一言で、いいです。「あっちのモデルに汚染されている箇所は?」という質問を発することを約束事にする。

もちろん、形式的ではなく、本気でチェックすること。

モデルを描くとき、外部のモデルを使っている箇所は、当然、色分けしておくべき。

ドメインの専門家たちとの会話で、言葉のギャップを発見したら「よそのモデル」の影響の可能性をチェックする。

ドメインの専門家に手伝ってもらいながら、シナリオテストを作成して、それを、継続的インテグレーションの自動テストに組み込むのも有効そうですね。
(Conformist パターンでなくても、やるべきことですけど)

Conformist パターンは「ソフトウェアの流用」なので、汚染の危険があるのは、開発者です。

ユビキタス言語


ドメインの専門家は、影響は受けない。

Conformist パターンの悪影響の予防、改善には、やはり、ドメインの専門家との対話を頻繁に行い、かれらの言葉、その使い方に注意深く耳をかたむけることでしょう。

そして、自分たちの言葉の選び方、使い方に、ドメインの専門家が違和感を感じていないか、敏感になること。

結局、「ユビキタス言語」パターンを、丁寧に、地道に続けることが、Conformist パターンの導入による「モデルのゆがみ」の、防止策・改善策の基本ですね。

それなりに使えるモデル、ソフトウェアを、上流チームが提供してくれるなら、Conformist パターンは、検討の価値がありそうです。「それなり」という判断が、めちゃくちゃ難しそうですけど...

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM