Domain-Driven Design ドメイン駆動の設計 | システム設計日記
ドメイン(domain)の語源は、「支配している場所と」か「領地」という意味らしい。この線からこっち側はオレ様の領地、という感じですかね。 Domain-Driven Design(DDD)に、Bounded Context（コンテキスト境界）パターンがある。個々のドメイン（領地）の境界線をきちんとして、境界を越えて干渉しないようにすべし、という考え方ですね。これ、ドメインのもともとの意味を、再確認して強調しているだけなのね。 ソフトウェアは、何かを解決するために開発する。だから、ソフトウェア開発は、まず、その問題（の領域）を正しく理解することから始まる。そういう意味では、どんなソフトウェア開発も Domain-Driven Design なんだと思います。 まあ、問題領域の理解が浅かったり、関係者間で理解がばらばらだったりすると、悲惨な結果になるわけですが、ドメイン駆動というのは、ソフト
Shared Kernel パターン は、たぶん アンチパターン | システム設計日記
二つの Bounded Context を、別のチームで開発していると、コードやデータベースにかなり重複が目立つことがある。 Shared Kernel パターンは、そういう状況を改善するために、 ・特に重複がひどい箇所を、共通化すべき領域として特定し ・２つのチームが相談しながら ・共通モジュール（Shared Kernel) を開発・維持する ことに取り組もう、というやり方ですね。 なぜ、そういう状況が起きるか? 別の Bounded Context なのに、なぜ、そんなに重複が多いか？ 本来は、ひとつの Bounded Context として扱うべき問題を、なんらかの事情で、２つのチームに分けて開発しているからなんだと思う。 ありがちなケースは、開発メンバーは大勢いるが、経験不足・スキル不足のメンバーが大半、という状況。 １０人のメンバーが、ひとつのチームとして開発するのは、現実的で
システム設計日記
テスト駆動開発 和田卓人(t-wada)さんによる『テスト駆動開発』の新訳版が出版されました。 オブジェクト指向でソフトウェアを開発するのであれば、この本とマーチンファウラーの『リファクタリング』は必読書だと思います。この古典ともいえる『テスト駆動開発』が和田さんの手によって新訳版として復刊されたことは、ほんとうにすばらしいことです。 この本が出版された経緯と、和田さんはじめ関係者の方々のご努力については、和田さんの、このブログをぜひ読んでいただければと思います。 新訳版『テスト駆動開発』が出ます 新訳本は、単に原著が日本語で読めるようになっただけではありません。和田さんの手によって、原著にはない新たな価値が付け加えらました。 一つは、サンプルコードの工夫です。 できるだけ省略はしない変更箇所を目立つようにした各章末にその時点での全コードを記載する これらの工夫により、本に書かれた内容が、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
