Practical DDD #4: ユビキタス言語とモデル
ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。 思考を図にする書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。 ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理（コンテキストマップや大規模な構造など、第14章と第16章で説明するもの）に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。 エリック・エヴァンスのドメイン駆動設計 第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25) この文章が言わんとしていることを私の理解で図にしてみました。 この図は、上に挙げた段落の
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 Symfony #6: Symfony2の@apiアノテーションによる後方互換性の維持管理
この記事はSymfony Advent Calendar JP 2011の24日目の記事です。 速いペースでマイナーバージョンアップされるSymfony2Symfony2は、2011年7月に2.0がリリースされて以降、概ね月に1回のペースでメンテナンスリリースをしています。私自身が開発に携わっている案件でも、何度かこのようなメンテナンスリリースによるSymfony2本体のバージョンアップを行いましたが、直接的な問題はほぼ発生していません。フレームワークの更新というと、マイナーバージョンアップでさえ事前に変更点をしっかり調査し、適用しても問題がないという調査・判断が必要でした。Symfony2でももちろん事前に変更内容を調査することは必要ですが、Symfony2側で後方互換性が維持されるルールが導入されており、上手く機能しているようです。 この「後方互換性を維持するルール」の中心となるのが「
Practical Symfony #25: Routerを拡張してURLのサブディレクトリを横断的に処理する
Symfony Advent Calendar 2014 (Qiita) 4日目 前(12月3日 ) 次(12月5日) Webサービスで、ユーザーのアカウントごとにサブディレクトリを割り当てたいとします（最近はユーザーアカウントごとにサブドメインを割り当てる方が主流かもしれませんが）。例えば次のような形です。 トップページ http://example.com/ユーザー hidenorigoto のコンテンツ http://example.com/hidenorigoto/profilehttp://example.com/hidenorigoto/report/20141124ユーザー someone のコンテンツ http://example.com/someone/profilehttp://example.com/someone/report/20141124このような形をとるシス
ドメインモデルのための型「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」パッケージをライブラリ
Practical Symfony #26: PHPMentorsPageflowerBundleを使ったページフロー定義と対話の管理
Symfony Advent Calendar 2014 (Qiita) 10日目 前(12月9日)次(12月11日)PHPMentorsPageflowerBundleは筆者が開発したSymfonyアプリケーション向けのページフローエンジンです。特徴としては、以下のものが挙げられます。 アノテーションによるページフロー定義対話の管理アクセス制御されたアクション対話スコープのプロパティ対話開始直後に実行されるユーザー定義メソッド複数のブラウザーウィンドウまたはタブのサポートPHPMentorsPageflowerBundleを使うと、コントローラーに断片的に埋め込まれたページフローに関するコードを明示的な定義で置き換えることができます。また、対話と対話スコープのプロパティの導入によってコントローラーの状態管理コードを大幅を削減することができます。 では、早速コードを見てみましょう。以下はS
「ドメインモデリングにおける関数型パターン―仕様パターン」を翻訳しました
書籍「実践ドメイン駆動設計 (Object Oriented Selection)」が出版されて、ドメイン駆動設計（DDD）の知名度が上がってきているようです。 そのDDDに関連する分野の１つとして、DSL（ドメイン特化言語）を挙げることができると思います。 デバシッシュ・ゴーシュさん（Debasish Ghosh）は、DSLのエキスパートで、「実践プログラミングDSL」（原題 “DSLs in Action"）という本を出されています。この本の第１章のタイトルは、「ドメインの言葉を話す方法を学ぶ」となっています。 デバシッシュさんのブログ記事のうちの１つ、"Functional Patterns in Domain Modeling - The Specification Pattern” に惹かれて、翻訳をしました。翻訳記事の公開について、著者ご本人から快諾頂けたため、以下に掲載させて
PHPメンターズ -> 第40回IT勉強宴会モデリング競演2でDDDのモデリングについて発表しました
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 公式アカウントに
Pimpleでシンプルに正しくDIを理解する
オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency
Debasish Ghosh氏のブログ記事「ドメイン駆動設計：可変性の管理」を翻訳しました
ドメイン駆動設計が、今、世界的に盛り上がりを見せています。2016年1月には、Domain-Driven Design Europeが開催されるそうです。このイベントのスピーカー＆ワークショップ講師の１人として、Jim Coplien氏の名前が載っています。Jim Coplien氏は、日本だと、「組織パターン」の著者として、また、DCIアーキテクチャの人として有名ですが、ドメインエンジニアリングの研究者でもあります。 Eric Evans氏のDDD本は、サブタイトルが、「ソフトウェアの核心にある複雑さに立ち向かう」となっています。複雑さとは何か、それを管理する技術とは何か、古くて新しい問題です。Jim Coplien氏の著作「マルチパラダイムデザイン」では、ドメインとは何か、どのように設計を行うべきかについて書かれています（残念ながら絶版です。） Debasish Ghosh（デバシッシュ
PHPカンファレス2015 PHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」参加レポート
2015年10月03日にPHPカンファレンス2015内で、ミニカンファレンスとして開催されたPHPメンターズセミナー「モデルを設計せよ！―ドメイン駆動設計を超えて」に参加してきました。 モデルを設計せよ！―ドメイン駆動設計を超えて視点PHPメンターズ 後藤秀宣 @hidenorigoto セッションのテーマは「視点」。いくつかの実例から、参加者が視点そのものについて実際に考えることができる体験的な講演でした。後藤さんのスライドに関しては公開は無しとのことです。このセミナーでは、この「視点」という言葉が全体を通じてのテーマになっていると思います。 特に印象深いのが「コップを空にする」話です。既にたくさんの知識を身につけた修行僧が、高名な僧侶のもとに学びに行きます。修行僧がひとしきり知識を披露した後、高名な僧侶は空の茶碗にお茶をそそぎ、そそぎ続けて、茶碗からお茶が溢れてしまってもそれをとめませ
関数・定数のラッパーオブジェクト（レガシープロキシー）を導入してテスト容易性を高める
PHPユーザーであれば、PHPが標準で持つ多くの内部（ビルトイン）関数や定数には日常的にお世話になっていることでしょう。これらの内部関数・定数はPHPの便利さの象徴といえます。しかし、内部関数や定数の使用はテストのしやすさを低下させる原因となります。以下のコードを見てみましょう。 <?php ... class CollectingType { protected $type; protected $expectedSuperTypes = array(); ... public function isTest() { if (in_array($this->type, $this->expectedSuperTypes)) { return false; } else { foreach ($this->expectedSuperTypes as $expectedSuperType)
Symfonyの本「基本からしっかり学ぶSymfony2入門」を執筆しました
この記事は、Symfonyアドベントカレンダー2015の6日目の記事です。昨日は@okapon_ponさんの「Symfonyでdebug環境を最適化しコードを追いやすくする」でした。 12月16日付けで、技術評論社様より『基本からしっかり学ぶSymfony2入門』が出版されます。最初に企画書を書いたのが2014年の3月で、そこから出版まで2年近く時間がかかりました。この本ではSymfony 2.7を対象としていますが、書き始めた頃はまだSymfony 2.3の時代でした。今ではすでに2.8と3.0もリリースされているので、バージョンの進み具合だけとっても執筆に結構長くかかってしまったと感じます（苦労させられた点でもありますが）。執筆は、私（後藤）とカルテットコミュニケーションズの金本さんとの共著になっています。 技術評論社 書籍紹介ページすでにAmazonでご予約頂いている方も多数いらっし
コネクタとしての BEAR.Resource について考えたこと
BEAR.Sunday Advent Calendar 2015 6日目の記事です。（※記事の公開が予定よりも遅れてしまいました。すみません。） RESTfulフレームワークである BEAR.Sunday を使う機会がありました。 使ってみて考えたことを書きたいと思います。この記事では、まずコネクタとしてのリソース（BEAR.Resource）について説明します。リソースの単位を 1. 名詞的情報にした場合と、 2. ドメインユースケースにした場合 についてそれぞれ特徴を検討します。後者については説明用に動作するスニペットを組みました。 BEAR.Resource とは BEAR.Sunday を構成するオブジェクトフレームワークの１つに BEAR.Resource があります。READMEには下記の記述があります。 BEAR.Resource はオブジェクトがリソースの振る舞いを持つHy
Practical Symfony #27: コンパイルタイムファクトリ（Compile Time Factories）
この記事はSymfony Advent Calendar 2015 8日目の記事です。前日の記事は@__tai2__さんの「DQLのJOIN WITH構文を使えば、無用な関係を定義せずにテーブルの結合ができる」でした。 ファクトリ（Factories）は、オブジェクトの生成（Creation）に関するデザインパターンで、オブジェクトまたはオブジェクトグラフの組み立て方法についての知識（構成の知識）を集約するものです。Eric Evans氏（@ericevans0）の提唱するドメイン駆動設計（Domain-Driven Design: DDD）のビルディングブロックの1つとしても知られています。 論理的にはファクトリは以下のような構造を持ちます。 クラスまたはメソッドによるファクトリ クラスまたはメソッドを使ったファクトリはPHP + Symfonyの環境における基本型といえます。その構造は
Zend\Diを使ったDIの自動ワイヤリング
「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。 今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ（Zend\Di）を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプロ
PHP Mentors
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 公式アカウントに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
