Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会＠大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては
PHPカンファレンス2013で「モデルとの向き合い方：ドメイン駆動設計体験ワークショップ」を行いました
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
Practical DDD #1: Specificationパターンの例
あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification（仕様）としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を（筆者注：仕様として）定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし
Practical Symfony #21: テンプレートで扱うユーティリティの書き方およびページオブジェクトの利用について考察
Symfonyでアプリケーションを開発している時に、Twigテンプレートで何度に記述しているビューロジックやフォーマット処理を何処かにまとめたいと考えることが頻繁にあります。複数のプロジェクトで使いまわせるような汎用的な処理はTwig拡張として独自のタグや関数、フィルタにしてしまうと便利ですが、アプリケーション固有の処理で、かつたくさんの種類があると、それらをいちいちTwigの関数などにするのは手間です。 かといって、テンプレートに渡ってくるエンティティオブジェクトにアプリケーション用のフォーマットメソッドなどを実装し始めると、とたんにエンティティオブジェクトにメソッドが増えてしまいます。そもそもこれはアプリケーション側の要求であり、ドメインオブジェクトに持たせるべきものではありません。 そこで、コントローラからテンプレートをレンダリングする時に、ページオブジェクトという中間オブジェクトを
Kata #1 - サービス（SERVICES）
DDDを適用した開発スタイル「PHPメンターズ流 設計と実装の型」の解説シリーズ 其の壱：サービス 概要ドメインのユースケース（ビジネスユースケース／シナリオ）をソフトウェアとして表現する際、サービス（ドメインサービス）としてモデリングします。 型の派生元DDD p.103「サービス（SERVICES）」 詳細ドメインモデルをユースケース分析した場合、そのユースケースのシナリオが直接的にあらわれる場がサービスになります。これとは対照的に、ドメインモデルのデータ構造があらわれるのがエンティティやバリューオブジェクトになります。エンティティやバリューオブジェクトには、それ自身が持つ振舞のみを持たせ自己完結するようにしておき、そこにおさまらないシナリオ／手順はサービスにします。エンティティはオブジェクト本来の役割に近く状態を持つのに対して、サービスは手順なので状態を持ちません。 ユビキタス言語で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT-Benkyoenkai_2015-04-25_01Goto.pdf
