Specification パターン ：複雑な ビジネスルールの表現手段 | システム設計日記
Domain-Driven Design(DDD)の９章 "Making Implicit Cocepts Explicit" ( はっきりしない概念を明確にする) では、かなりのページを使って、Specification パターンを説明している。 ・仕様を満たすこと ・こういう条件を満たすこと という種類のビジネスの約束事を表現するドメインオブジェクトの設計・実装パターンの議論。 エバンスは、このパターンがお気に入りらしく、１８ページを使って解説している。 はっきりしない概念として取り上げた「制約(ビジネスルール)」と「業務手順」の議論は、たったの４ページなのにね。 動機：複合条件を表現する 単純な if 文で判定できる場合は、良いけど、 ( Java 経験５年以上 OR C# 経験５年以上) AND ( 東京在住 OR 転居可能 ) AND ( 文系 OR 読書好き ) AND ( 好
Shared Kernel パターン は、たぶん アンチパターン | システム設計日記
二つの Bounded Context を、別のチームで開発していると、コードやデータベースにかなり重複が目立つことがある。 Shared Kernel パターンは、そういう状況を改善するために、 ・特に重複がひどい箇所を、共通化すべき領域として特定し ・２つのチームが相談しながら ・共通モジュール（Shared Kernel) を開発・維持する ことに取り組もう、というやり方ですね。 なぜ、そういう状況が起きるか? 別の Bounded Context なのに、なぜ、そんなに重複が多いか？ 本来は、ひとつの Bounded Context として扱うべき問題を、なんらかの事情で、２つのチームに分けて開発しているからなんだと思う。 ありがちなケースは、開発メンバーは大勢いるが、経験不足・スキル不足のメンバーが大半、という状況。 １０人のメンバーが、ひとつのチームとして開発するのは、現実的で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
