はてなブックマーク

増田亨氏の「現場で役立つシステム設計の原則]」批判の第２編です。 （２）ポリモーフィズムは何のために？オブジェクト指向の要件本書には「変更を楽で安全にするオブジェクト指向の実践技法」というサブタイトルが付与されています。オブジェクト指向が何かという点については、論者によって違いはあるものの、以下の３つが要件とされることには、多くの人が合意するでしょう。 カプセル化インヘリタンス（継承）ポリモーフィズム（多態）前回で明らかになったように、カプセル化は、オブジェクト指向とは独立にモジュール分割の指導原理としてデイビッド・パーナスにより提唱された「情報隠蔽」を敷衍したものです。オブジェクト指向の要件ではありますが、オブジェクト指向固有のアイデアではありません。 インヘリタンスは便利な機能ですが、コンポジションや移譲により代替できるので、オブジェクト指向の本質的な要件とは見做されなくなってきたかと

増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本

Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)  ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。 こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。 この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもし

Domain-Driven Design (DDD) intersects with a broad range of the intellectual heritage in the software design discipline including object-orientation, design patterns and refactoring. And as such, it can be viewed as a synthesis of these knowledge assets tailored towards domain-oriented application software development. Although this view is valid and productive, there could be another way of viewi

BEAR.Sunday Advent Calendar 2015 6日目の記事です。（※記事の公開が予定よりも遅れてしまいました。すみません。） RESTfulフレームワークである BEAR.Sunday を使う機会がありました。 使ってみて考えたことを書きたいと思います。この記事では、まずコネクタとしてのリソース（BEAR.Resource）について説明します。リソースの単位を 1. 名詞的情報にした場合と、 2. ドメインユースケースにした場合 についてそれぞれ特徴を検討します。後者については説明用に動作するスニペットを組みました。 BEAR.Resource とは BEAR.Sunday を構成するオブジェクトフレームワークの１つに BEAR.Resource があります。READMEには下記の記述があります。 BEAR.Resource はオブジェクトがリソースの振る舞いを持つHy

現在の時刻を扱うロジックがアプリケーションコードに含まれるのは珍しいことではありませんが、これらのロジックのテストは簡単ではありません。以下のコードを見てみましょう。 <?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オブジェクトの生成部分をメソッドとして抽出し、そのメソッド

Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計

ドメイン駆動設計が、今、世界的に盛り上がりを見せています。2016年1月には、Domain-Driven Design Europeが開催されるそうです。このイベントのスピーカー＆ワークショップ講師の１人として、Jim Coplien氏の名前が載っています。Jim Coplien氏は、日本だと、「組織パターン」の著者として、また、DCIアーキテクチャの人として有名ですが、ドメインエンジニアリングの研究者でもあります。 Eric Evans氏のDDD本は、サブタイトルが、「ソフトウェアの核心にある複雑さに立ち向かう」となっています。複雑さとは何か、それを管理する技術とは何か、古くて新しい問題です。Jim Coplien氏の著作「マルチパラダイムデザイン」では、ドメインとは何か、どのように設計を行うべきかについて書かれています（残念ながら絶版です。） Debasish Ghosh（デバシッシュ

オブジェクト指向でソフトウェアを実装していると、オブジェクトの生成に一連の手続きが必要なものがでてきます。このような生成に関する手続きがあちこちのソースコードへ散在すると、望ましくない状況になることは想像に難くないでしょう。この問題に対処するために、Simple FactoryやFactory Methodといったデザインパターンがあり、オブジェクトの生成に関する手続きや関連オブジェクトも含めたオブジェクトの構成（オブジェクトコンストラクション）に関する知識は1箇所にまとめるということが定石となっています。 しかし、単にファクトリーを導入するだけだと、オブジェクトの構成処理は分離・隠蔽できても、利用オブジェクトがファクトリー自体に依存してしまうことになります。このような試行錯誤の歴史から登場したのがDependency Injection(依存性の注入)パターンです。Dependency

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 公式アカウントに

書籍「実践ドメイン駆動設計 (Object Oriented Selection)」が出版されて、ドメイン駆動設計（DDD）の知名度が上がってきているようです。 そのDDDに関連する分野の１つとして、DSL（ドメイン特化言語）を挙げることができると思います。 デバシッシュ・ゴーシュさん（Debasish Ghosh）は、DSLのエキスパートで、「実践プログラミングDSL」（原題 “DSLs in Action"）という本を出されています。この本の第１章のタイトルは、「ドメインの言葉を話す方法を学ぶ」となっています。 デバシッシュさんのブログ記事のうちの１つ、"Functional Patterns in Domain Modeling - The Specification Pattern” に惹かれて、翻訳をしました。翻訳記事の公開について、著者ご本人から快諾頂けたため、以下に掲載させて

Symfony Advent Calendar 2014 (Qiita) 10日目 前(12月9日)次(12月11日)PHPMentorsPageflowerBundleは筆者が開発したSymfonyアプリケーション向けのページフローエンジンです。特徴としては、以下のものが挙げられます。 アノテーションによるページフロー定義対話の管理アクセス制御されたアクション対話スコープのプロパティ対話開始直後に実行されるユーザー定義メソッド複数のブラウザーウィンドウまたはタブのサポートPHPMentorsPageflowerBundleを使うと、コントローラーに断片的に埋め込まれたページフローに関するコードを明示的な定義で置き換えることができます。また、対話と対話スコープのプロパティの導入によってコントローラーの状態管理コードを大幅を削減することができます。 では、早速コードを見てみましょう。以下はS

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」パッケージをライブラリ

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このような形をとるシス

この記事はSymfony Advent Calendar JP 2011の24日目の記事です。 速いペースでマイナーバージョンアップされるSymfony2Symfony2は、2011年7月に2.0がリリースされて以降、概ね月に1回のペースでメンテナンスリリースをしています。私自身が開発に携わっている案件でも、何度かこのようなメンテナンスリリースによるSymfony2本体のバージョンアップを行いましたが、直接的な問題はほぼ発生していません。フレームワークの更新というと、マイナーバージョンアップでさえ事前に変更点をしっかり調査し、適用しても問題がないという調査・判断が必要でした。Symfony2でももちろん事前に変更内容を調査することは必要ですが、Symfony2側で後方互換性が維持されるルールが導入されており、上手く機能しているようです。 この「後方互換性を維持するルール」の中心となるのが「

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

ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。 思考を図にする書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。 ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理（コンテキストマップや大規模な構造など、第14章と第16章で説明するもの）に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。 エリック・エヴァンスのドメイン駆動設計 第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25) この文章が言わんとしていることを私の理解で図にしてみました。 この図は、上に挙げた段落の

プログラミング道場生 kumamidori です。 「ドメイン駆動設計」読書会の第8回に参加しました。内容は、こちらのWikiにまとめられています。 この記事の前半では、復習として、関連、エンティティ、値オブジェクトについて、自問自答のQ&A形式でメモします。この道の先人から教えて頂いた内容が多いです。教えて下さった方、ありがとうとざいました。後半で、勉強会後に見つけた値オブジェクトのPHPサンプルを引用して紹介します。 Q&A 関連 Q. 情報と情報の関連は、（双方向ではなく）できるだけ一方向にすること、関連を限定することにより、 管理しやすくなる、という話があった。適切に関連を見出せるかどうかは、業務分析にかかっている。間違いなくそれを行うことはかなり難しいのでは？ A. 一発ではできない。設計、実装しながらモデルを直していく（蒸留）。 関連は、業務のユースケースにより決まってくる。ユ