2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会@大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては
まず、従来のシステム開発とジェネレーティブプログラミング(GP: Generative Programming)なシステム開発を図で見比べます。 ジェネレーター:ドメイン特化言語(DSL: Domain-Specific Languages)をソースコード・実行可能なバイナリ・別のモデルへと変換するプログラム ドメイン知識:ユーザーの関心が寄せられている知識の体系 GPのパラダイムシフトにより、システム開発におけるドメインエキスパート(問題ドメイン)の仕事は開発者への説明でなくDSLの記述とジェネレータへの入力へ、開発者の仕事(解決ドメイン)は個別のアプリケーションの開発でなくジェネレーターの開発へと変わっていくはずであると説明されています。 更に、DSLであらわされるドメイン知識は、単に現在の業務そのものでも業務を要約したものでもなく、業務を論理によって整理し、構成しなおしたものであるべ
配列、連想配列といったデータの集まり - 集合に対する操作は、日々のプログラミングにおいて頻繁に記述するコードの1つです。その一方で、旧来の愚直なループを使った集合操作はコードを複雑にする大きな要因となります。これに対処するために、Microsoftは統合言語クエリ:LINQ(Language-Integrated Query)を開発しました。LINQ to Objectsのページには、LINQを使うメリットとして次のように説明があります。 本質的に、LINQ to Objects は、コレクションを扱うための新しい方法です。 従来の方法では、複雑な foreach ループを記述して、コレクションからどのようにデータを取得するかを指定する必要がありました。 LINQ を使用する場合は、何を取得するかを表す宣言コードを記述します。 また、LINQ クエリには、従来の foreach ループと
TL;DR GOOS本『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト(依存オブジェクト、隣接オブジェクト)はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら
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 公式アカウントに
あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification(仕様)としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を(筆者注:仕様として)定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし
Symfonyでアプリケーションを開発している時に、Twigテンプレートで何度に記述しているビューロジックやフォーマット処理を何処かにまとめたいと考えることが頻繁にあります。複数のプロジェクトで使いまわせるような汎用的な処理はTwig拡張として独自のタグや関数、フィルタにしてしまうと便利ですが、アプリケーション固有の処理で、かつたくさんの種類があると、それらをいちいちTwigの関数などにするのは手間です。 かといって、テンプレートに渡ってくるエンティティオブジェクトにアプリケーション用のフォーマットメソッドなどを実装し始めると、とたんにエンティティオブジェクトにメソッドが増えてしまいます。そもそもこれはアプリケーション側の要求であり、ドメインオブジェクトに持たせるべきものではありません。 そこで、コントローラからテンプレートをレンダリングする時に、ページオブジェクトという中間オブジェクトを
DDDを適用した開発スタイル「PHPメンターズ流 設計と実装の型」の解説シリーズ 其の壱:サービス 概要ドメインのユースケース(ビジネスユースケース/シナリオ)をソフトウェアとして表現する際、サービス(ドメインサービス)としてモデリングします。 型の派生元DDD p.103「サービス(SERVICES)」 詳細ドメインモデルをユースケース分析した場合、そのユースケースのシナリオが直接的にあらわれる場がサービスになります。これとは対照的に、ドメインモデルのデータ構造があらわれるのがエンティティやバリューオブジェクトになります。エンティティやバリューオブジェクトには、それ自身が持つ振舞のみを持たせ自己完結するようにしておき、そこにおさまらないシナリオ/手順はサービスにします。エンティティはオブジェクト本来の役割に近く状態を持つのに対して、サービスは手順なので状態を持ちません。 ユビキタス言語で
現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?php ... class OrderService { ... public function order(Order $order) { $currentHour = (integer) (new \DateTime())->format('H'); if ($currentHour >= 10 && $currentHour < 21) { ... } else { throw new OrderException('ご注文は午前10時から午後9時まで!'); } } ... 実際の現在の時刻に依存せずにif文の条件をテストする1つの方法は、DataTimeオブジェクトの生成部分をメソッドとして抽出し、そのメソッド
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 公式アカウントに
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 公式アカウントに
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 公式アカウントに
Symfony Advent Calendar JP 2012 - Day 6 今回はStagehand_TestRunner、Piece_Flow等、Piece Frameworkのいくつかのプロダクトで使われているConfigコンポーネントについて解説します。 Symfony ConfigコンポーネントConfigコンポーネントはソフトウェアの可変部分を表現する言語を定義し、処理するためのフレームワークです。Symfonyフレームワークにおいてはバンドルおよびその背後にあるコンポーネントの可変部分をユーザーが構成するために使われています。 Configコンポーネントが取り扱うのは一般的に設定や構成と呼ばれるものです。 設定はDSLである ドメイン固有言語 (DSL) は特定用途向けの言語です。ドメイン固有言語は、システムファミリの具体的なメンバを「発注」するのに使い、ゆえにジェネレーテ
「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。 今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ(Zend\Di)を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプロ
Piece FrameworkのプロダクトのひとつStagehand_TestRunnerは、CLIでユニットテストを実行するための継続的テストランナーです。Stagehand_TestRunner v3の実装には多くのSymfonyコンポーネントが使われています。今回はStagehand_TestRunnerを動作させる上で重要な役割を果たしているDependency Injectionコンポーネントについて具体的な使い方を解説します。 Symfony Dependency InjectionコンポーネントDependency InjectionコンポーネントはSymfonyにおけるDIコンテナの実装であり、WebアプリケーションフレームワークとしてのSymfonyの基盤となるプロダクトです。サービスの依存性とその注入方法の定義、サービスの作成・取得、サービスへの依存性の注入、といったD
PHPにはvar_dump()という関数があり、階層構造を持つオブジェクト(オブジェクトグラフ)をテキスト表現にできます。この情報を、グラフィカルで直感的に分かりやすい形式で出力するためのユーティリティがprint_oです。@koriymさんが開発されています。 koriym/print_o An object graph visualizer for PHPprint_oのインストール方法print_oはPHPのライブラリとしては単独で利用可能です。Webブラウザへの描画用に外部のJavaScript/CSSを利用していますが、これらはGoogleやGitHubにホストされたファイルを読み込むようになっています。したがってインターネットに接続された環境であれば、print_o本体のインストール以外に特別な手順は不要です。 たとえばcomposerを利用する場合は、composer.jso
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成(オブジェクトコンストラクション)に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
こんにちは。 まっつんこと松藤です。 まっつんチャレンジとは?ITEMAN Blogで不定期連載していたまっつんチャレンジが、場所を移して約2年8ヶ月ぶりに再開することになりました。まっつんチャレンジとは、プログラミング言語や環境に関わらず技術的には大変興味深いけれど試すのが大変面倒くさそう難しそうなフレームワークやライブラリに私まっつんが挑戦し、それらがどんなものであるのかを私なりに皆様にお届けするシリーズです。 再開の第1回目はScalaのWebアプリケーションフレームワークPlay Framework 2.0です。 Play FrameworkはJavaとScalaをネイティブサポートしたWebアプリケーションフレームワークです。非同期処理やNoSQLデータベースのサポートといった先進的な機能を備えているのですが、今回はルーティングやコントローラ、テンプレートといったWebアプリケー
Symfony2のフォームでCollectionTypeを使う方法について、第1回ではエンティティクラスと対応付けたFormTypeクラスを作る部分を解説しました。作成したFormTypeは、以下のようにAnswerTypeとAnswerDetailTypeで親子関係を持っています。 今回は、フォームのレンダリングとFormViewについて見てみましょう。 デフォルトのレンダリングフォームにはデフォルトのレンダリングエンジンがあり、FormTypeで定義したウィジェットを階層構造も含めて手軽にレンダリングすることができます。コントローラでテンプレートをレンダリングする時に‘form’ => $form->createView()のようにしてFormViewインスタンスをformという変数名で渡している場合、テンプレート側では{{ form_widget(form) }}とするだけで、このフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く