Practical DDD #1: Specificationパターンの例
あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification（仕様）としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を（筆者注：仕様として）定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし
DDDの仕様パターン - pospomeのプログラミング日記
-----------追記------------- 仕様パターンについては以下の書籍で可能な限り詳しく解説しています。 興味あれば読んでみてください。 pospome.booth.pm -----------追記おわり------------- エリック・エヴァンスのDDD本では「仕様パターン」という実装パターンが説明されている。 仕様上のバリデーションはエンティティや値オブジェクトに実装してはいけない。 複雑な仕様による複雑なバリデーションロジックは クラスの肥大化を招いてしまう。 class User { //こういったバリデーションは肥大化を招く public boolean isXXX(){ //複雑なロジック } } また、こういったバリデーションは複数のエンティティを必要とする場合があるので、 どのクラスの責務とするのかを明確に判断できないこともある。 class User
郵便番号-住所検索API
郵便番号データをパラメータに含めてリクエストを送信することで、都道府県、市区町村のデータをJSONフォーマットで返却するシンプルなサービスです。 通常のHTTPリクエストAPIに加えて、SDKを利用したJSONPリクエストにも対応しています。詳しくはSDKの項を御覧ください。 データベースを使わず、静的なファイルベースでのレスポンスなので、割と高速に動作します。 利用規約に同意頂ける方のみご利用ください。また、当サイトやAPIに関する質問はフォームを用意していませんので、@sugimoto1981 までmensionなど頂ければ時間のある時にお答えできると思います。 改訂履歴 [2015-10-15] APIレスポンスの返却フィールドにcity及びtownの値を追加しました。この変更による過去バージョンへの影響はありません。 [2018-07-10] 本サイト及びAPIサーバのHTTPS更
CQRS+Event Sourcingを学ぶための教材 - かとじゅんの技術日誌
超久しぶりのブログ…。 Octopressに疲れたのではてなブログに戻ってきました(Octopressの過去の記事ははてなブログにインポート済です)。ついでプロに移行。 さて、海外のDDDコミュニティではCQRS+Event Sourcing(以下, ES)が人気なのですが、ようやく日本でも話題になることが多くなったので今回は教材となりそうな書籍を簡単に紹介したいと思います。 DDD といえば まず エリック・エヴァンスのドメイン駆動設計 (以下 DDD本) を読むべきですが、CQRSについては記載がないので 実践ドメイン駆動設計 を読みましょう。 実践ドメイン駆動設計 作者: ヴァーン・ヴァーノン出版社/メーカー: 翔泳社発売日: 2015/03/19メディア: Kindle版この商品を含むブログ (2件) を見る さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれ
ドメイン駆動設計という仕事の流儀
8. ドメインモデル指向の設計パターン 業務活動のトリガー 業務手順の要約 業務の知識 ドメイン 起動 ドメイン 委譲 ドメイン イベント サービス モデル 入会申込 受付() -申込番号 { 会員とは？ -氏名 検証(); 入会とは？ -連絡先 記録(); 申込とは？ -申込日時 通知(); 受付とは？ } "something interesting "represents a Use Case scenario" “an Object Model which affects the domain" "delegate to other objects " of the Domain” [EAA-dev, Fowler] [GRASP : Controller] [PoEAA] 9. ドメイン層の基本部品 業務イベント 入会申込 会員リポジトリ 会員登録サービス << interfac
ドメイン層の構造の改善 ： Evolving Order パターン | システム設計日記
ドメイン層のオブジェクト群を、どういう視点で整理し、ドメイン層の構造を、どうやって育てていくか？ アプリケーション全体の構造 私たちのデフォルトのレイヤアーキテクチャは、 ■インタフェース （UI、REST API、... ) ■アプリケーションサービス ■ドメイン ■インフラストラクチャ（永続化、メッセージング） です。 アプリケーションサービスは、ドメイン層の薄いファサード。 実際の仕事は、ドメインのオブジェクトに委譲する。 ドメインで扱うデータの種類が増え、ビジネスのロジックが膨らんでくると、ドメイン層も、構造化して整理しないと、わけが分からなくなる。 初めはトランザクションスクリプトだった ドメイン駆動設計に取り組み始めたころは、ドメイン層の設計パターンは、ドメインモデルではなくトランザクションスクリプトでやっていた。 ユースケースごとに トランザクションスクリプトのクラスを作って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
