CONTINUOUS INTEGRATION (341ページ) †
要約 †
(p.341)
CONTINUOUS INTEGRATION (継続的インテグレーション)
BOUDED CONTEXTを定義したのであれば、それを正しく保たねばならない。
＊＊＊
同じBOUDED CONTEXTに従事する人数が多くなると、モデルが断片化してしまう傾向が強くなる。けれども、より小さなCONTEXTSにシステムを分割してしまうと結局は統合と一貫性の価値を失ってしまう。
誰かがモデリングしたオブジェクトや相互作用の意味を充分に理解せず、元々の目的に適さないような変更してしまう開発者がいるかもしれない。他のモデルですでに具現化した概念に気づかずに、その概念と振舞いを複製するかもしれない。気づいていながらも手に入れることを恐れてしまい、その概念と振舞いを複製するかもしれない。
システム開発のサイズに関わらず、必要となるコミュニケーション水準を保つことは非常に難しく、コミュニケーションを増やし、複雑さを減らす方法が必要である。また既存コードを壊すのが怖くてコードをコピーするような用心のしすぎを防ぐセイフティネットが必要である。
(p.342)
これらの問題を解決してくれるのがExtreme Programming(XP)である。多くのプラクティスが多くの人によって絶え間なく変更されていく設計の一貫性を保持するこの特定の問題に対処している。XPはその純粋な形式で統合化と良く相性が合うが、XPであろうとなかろうと、重要なのはCONTINUOUS INTEGRATIONのプロセスを持つことである。
CONTINUOUS INTEGRATIONとは、断片化が発生しても素早く感知し修正することができるように、コンテキスト中の全ての作業を頻繁にマージし一貫性を保つようにすることである。CONTINUOUS INTEGRATIONはDDDのほかの要素と同様に、(1)モデル概念の統合と(2)実装の統合の2つのレベルで作用する。
概念はチームメンバーの絶え間ないコミュニケーションによって統合される。チームは変化し続けるモデルの共通理解を養わないといけない。もっとも重要なのは絶えずUBIQUITOUS LANGUAGEを打ち出し続けることである。一方、実装物はシステム的なマージ/ビルド/テストプロセスによって統合され、そのプロセスによってモデルの断片化があぶりだされる。効果的なプロセスの多くは次の特徴を持つ:
- 段階的で再現可能なマージ/ビルド技術
- 自動化されたテストスイート
- 変更が統合化されていない期間を極力短く制限するルール
これらの裏返しに、めったに公式的には含まれないのが概念の統合である。
- モデルとアプリケーションの議論における絶え間ないUBIQUTOUS LANGUAGEの活動
多くのアジャイルプロジェクトは少なくとも日ごとのコードのマージを行っている。頻度は変更のペースによるが、他のチームメンバーが互いに矛盾する作業を行う前にマージされるべきである。
MODEL-DRIVEN DESIGNにおいて概念の統合は実装の統合もスムーズにする。一方、実装の統合はモデルの正当性と一貫性を証明し、モデルの断片化を明らかにする。
Therefore:
全てのコードと実装物を頻繁にマージするプロセスを確立しなさい。その際、素早く断片化に注意を向けられるよう自動化されたテストを実施しなさい。各個人の頭でモデルが進化するとともに、モデルの共通視点を打ち出すUBIQUITOUS LANGUAGEの活動を容赦なく実践しなさい。
CONTINUOUS INTEGRATIONは一つのBOUNDED CONTEXTの中でのみ有効である。翻訳が必要となるような隣接したCONTEXTとの設計課題についてこれらと同じペースで扱ってはいけない。
＊＊＊
CONTINUOUS INTEGRATIONは個々のBOUNDED CONTEXTの中で適用され、一つのモデルの統合化を保つ。複数のBOUNDED CONTEXTが共存するとき、あなたはそれらの関係とインターフェースについて検討しなければならない。。。
担当者のつぶやき †
- UBIQUTOUS LANGUAGEがドグマのように感じるのはまだDDDをしっかりと理解していないせい？
みんなの突っ込み †
- >UBIQUTOUS LANGUAGEがドグマのように・・・
いえいえ、しっかり理解していらっしゃるとと思いますよ。DDDでは UBIQUTOUS LANGUAGE 万歳！！！-- 池田?
