はじめに
今回はドメイン駆動設計におけるContinuous Integrationについて記述します。参考になった記事や引用した記事は適宜記載しますので、そちらもぜひ確認してください。
Continuous Integrationとは
Continuous Integration(CI)とは、継続的インテグレーションと呼ばれます。
以下CI(継続的インテグレーション)とは？より引用
開発者が書いた新しいコードとマスターブランチを頻繁に統合するプロセスを指します。新しい機能開発のためにブランチを作成する場合、つぎにマージするまでの期間が長くなるにしたがって変更量が多くなり、マージ作業が大変になるだけでなく、問題が含まれるコードの特定と分離が難しくなります。一回のコミットでの変更量を小さくして頻繁にマージすれば、問題の発見が早くなり対処が楽になります。また、問題発見のオーバーヘッドを小さくするために自動化されたテストを行うことが有効です。
DDDの公式リファレンスでは以下のように記載があります。
When a number of people are working in the same bounded context,there is a strong
tendency for the model to fragment.The bigger the team,the bigger the problem,but as few as three or four people can encounter serious problems. Yet breaking down the system into ever-smaller contexts eventually loses a valuable level of integration and coherency.
therefore :
Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly.Relentlessly exercise the ubiquitous
language to hammer out a shared view of the model as the concepts evolve in different
people’s heads.
簡単に翻訳すると、多くの人が同じ境界のあるコンテキストで作業している場合、強力なモデルが断片化する傾向。チームが大きくなればなるほど、問題は大きくなりますが、問題は少なくなります3～4人が深刻な問題に遭遇する可能性があるためです。それでもシステムを分解してコンテキストがますます小さくなると、貴重なレベルの統合と一貫性が最終的に失われます。それゆえ、すべてのコードとその他の実装成果物を頻繁にマージするプロセスを確立します。自動化されたテストにより、フラグメンテーションを迅速にフラグ付けします。それぞれの人々の中で概念がさまざまに進化するにつれて、モデルの共有ビューを打ち出すため、ユビキタスを絶え間なく行使する、と記載されています。
これまで、ドメインモデルの認識を関係者の中でそろえることが大切と述べてきました。その中でコンテキストを境界付け開発を進める必要がありました。では実際に開発を進めていく中で、コードは一人で作り上げられるものでしょうか。そうではなく、複数の関係者が協力して開発を進めていきます。よってコンテキストを境界付けたとしても日々開発者の頭はアップデートされていきます。そのため、マスターブランチに上がっているソースコードと個別のブランチを統合するタイミングで差異が大きいということはよくあります。そこでCIが登場するというわけです。頻繁にマスターブランチと個別ブランチを統合することで、差異を小さくし、問題の発見が早くなり対処が楽になるというわけです。
実際にCIを行った感想
私が従事するプロジェクトでもCIをがっつり使っています。
毎日自動でテスト行い、ソースコードのデグレエラーを早急に発見・対処しています。毎日テストを実施するため、どこでエラーが発生しているかなどの差分が発見しやすく、課題が大きくなる前に気づくことができています。実際にCIをするためのツールとしてJenkinsがあります。
以下参照
・Jenkinsとは？
まとめ
今回はCI(継続的インテグレーション)を紹介しました。CIに限らずDDDではドメインモデルを共有する関係者と認識を揃えることをポイントとしています。このCIもマスターブランチと個別ブランチの統合を頻繁に行うことで、ソースコードの差分を少なくしますが、それは各関係者の日々アップデートされる知識の差分を少なくし、認識のずれをなくすことにつながるのではないでしょうか。
Jenkinsというツールを用いて自動テストを実施するなど具体的な手法も次回以降記載していきたいと思います。