ドメインモデルのための型「Domain Kata」を使ってみました
Symfony Advent Calendar 2014 (Qiita) 6日目 前(12月5日 )次(12月7日 ) 「Domain Kata」について学んだことを書いて、Symfony2 サンプルアプリケーションでの使用例を紹介します。 Domain Kata についてDomain Kata Kata for domain models 公式 README の内容を日本語に訳すと下記となります（バージョン 1.2 現在）。 Domain Kata は、プロジェクトがモデルベース開発を実践するために、ドメインモデルの「型」を提供します。 モデルベース開発というのは、たとえば、ドメイン駆動設計、ジェネレ−ティブプログラミングといった手法を指します。 Domain Kata を使うことで、モデルの識別が容易になります。パッケージ構造を設計しやすくなります（「Model」パッケージをライブラリ
DIとサービスロケータの違い
DIとサービスロケータは、いずれもオブジェクトの構築と依存の解決という仕事を切り出すためのパターンです。ところで、この2つのパターンの違いを明確に説明できるでしょうか？ Pimpleでシンプルに正しくDIを理解する のコードは以下のようになっていました。 <?php require_once '../vendor/pimple/pimple/lib/Pimple.php'; // インフラ interface MailerInterface { public function send($body); } class SendmailMailer implements MailerInterface { public function send($body) { } } // ドメイン class NewsletterTransfer { protected $mailer; public
Practical DDD #1: Specificationパターンの例
あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification（仕様）としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を（筆者注：仕様として）定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
