タグ

phpmentorsに関するk-holyのブックマーク (31)

  • IT-Benkyoenkai_2015-04-25_01Goto.pdf

  • Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation

    2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会@大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては

    Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
  • 第29回 IT勉強宴会in名古屋「ジェネレーティブ・プログラミングの世界」参加レポート

    まず、従来のシステム開発とジェネレーティブプログラミング(GP: Generative Programming)なシステム開発を図で見比べます。 ジェネレーター:ドメイン特化言語(DSL: Domain-Specific Languages)をソースコード・実行可能なバイナリ・別のモデルへと変換するプログラム ドメイン知識:ユーザーの関心が寄せられている知識の体系 GPのパラダイムシフトにより、システム開発におけるドメインエキスパート(問題ドメイン)の仕事は開発者への説明でなくDSLの記述とジェネレータへの入力へ、開発者の仕事(解決ドメイン)は個別のアプリケーションの開発でなくジェネレーターの開発へと変わっていくはずであると説明されています。 更に、DSLであらわされるドメイン知識は、単に現在の業務そのものでも業務を要約したものでもなく、業務を論理によって整理し、構成しなおしたものであるべ

    第29回 IT勉強宴会in名古屋「ジェネレーティブ・プログラミングの世界」参加レポート
  • PHPにおける宣言的集合操作入門:Ginq

    配列、連想配列といったデータの集まり - 集合に対する操作は、日々のプログラミングにおいて頻繁に記述するコードの1つです。その一方で、旧来の愚直なループを使った集合操作はコードを複雑にする大きな要因となります。これに対処するために、Microsoftは統合言語クエリ:LINQ(Language-Integrated Query)を開発しました。LINQ to Objectsのページには、LINQを使うメリットとして次のように説明があります。 質的に、LINQ to Objects は、コレクションを扱うための新しい方法です。 従来の方法では、複雑な foreach ループを記述して、コレクションからどのようにデータを取得するかを指定する必要がありました。 LINQ を使用する場合は、何を取得するかを表す宣言コードを記述します。 また、LINQ クエリには、従来の foreach ループと

    PHPにおける宣言的集合操作入門:Ginq
    k-holy
    k-holy 2014/01/17
    分かりやすいGinqの使用例、Stringyも気になる https://github.com/danielstjules/Stringy
  • 状態ではなく、振る舞いをモックせよ

    TL;DR GOOS『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト(依存オブジェクト、隣接オブジェクト)はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら

    状態ではなく、振る舞いをモックせよ
    k-holy
    k-holy 2013/11/08
    モック使いすぎて何をテストしてるのか分からなくなる問題への対処法。ユースケースをクラス/メソッド化することでテスト対象を明確に。
  • 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 公式アカウントに

    PHPカンファレンス2013で「モデルとの向き合い方:ドメイン駆動設計体験ワークショップ」を行いました
  • Practical DDD #1: Specificationパターンの例

    あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification(仕様)としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を(筆者注:仕様として)定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし

    Practical DDD #1: Specificationパターンの例
  • Practical Symfony #21: テンプレートで扱うユーティリティの書き方およびページオブジェクトの利用について考察

    Symfonyでアプリケーションを開発している時に、Twigテンプレートで何度に記述しているビューロジックやフォーマット処理を何処かにまとめたいと考えることが頻繁にあります。複数のプロジェクトで使いまわせるような汎用的な処理はTwig拡張として独自のタグや関数、フィルタにしてしまうと便利ですが、アプリケーション固有の処理で、かつたくさんの種類があると、それらをいちいちTwigの関数などにするのは手間です。 かといって、テンプレートに渡ってくるエンティティオブジェクトにアプリケーション用のフォーマットメソッドなどを実装し始めると、とたんにエンティティオブジェクトにメソッドが増えてしまいます。そもそもこれはアプリケーション側の要求であり、ドメインオブジェクトに持たせるべきものではありません。 そこで、コントローラからテンプレートをレンダリングする時に、ページオブジェクトという中間オブジェクトを

    Practical Symfony #21: テンプレートで扱うユーティリティの書き方およびページオブジェクトの利用について考察
  • Kata #1 - サービス(SERVICES)

    DDDを適用した開発スタイル「PHPメンターズ流 設計と実装の型」の解説シリーズ 其の壱:サービス 概要ドメインのユースケース(ビジネスユースケース/シナリオ)をソフトウェアとして表現する際、サービス(ドメインサービス)としてモデリングします。 型の派生元DDD p.103「サービス(SERVICES)」 詳細ドメインモデルをユースケース分析した場合、そのユースケースのシナリオが直接的にあらわれる場がサービスになります。これとは対照的に、ドメインモデルのデータ構造があらわれるのがエンティティやバリューオブジェクトになります。エンティティやバリューオブジェクトには、それ自身が持つ振舞のみを持たせ自己完結するようにしておき、そこにおさまらないシナリオ/手順はサービスにします。エンティティはオブジェクト来の役割に近く状態を持つのに対して、サービスは手順なので状態を持ちません。 ユビキタス言語で

    Kata #1 - サービス(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オブジェクトの生成部分をメソッドとして抽出し、そのメソッド

    時計オブジェクト(ドメインクロック)を導入してテスト容易性と意図性を高める
    k-holy
    k-holy 2013/04/05
    時計オブジェクトを導入してテスト容易に。グローバルな設定オブジェクトに日時持ったりしてたけどこの方が綺麗ですね
  • Symfony2ベースのユーザー登録サンプルを公開しました

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

    Symfony2ベースのユーザー登録サンプルを公開しました
  • PHPカンファレンス2012で「実践Dependency Injection」の講演を行いました

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

    PHPカンファレンス2012で「実践Dependency Injection」の講演を行いました
  • WEB+DB PRESS PHP連載第4回「HTTPでのキャッシュとESI」を執筆しました

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

    WEB+DB PRESS PHP連載第4回「HTTPでのキャッシュとESI」を執筆しました
  • Pieceの中のSymfony #4: Configコンポーネント

    Symfony Advent Calendar JP 2012 - Day 6 今回はStagehand_TestRunner、Piece_Flow等、Piece Frameworkのいくつかのプロダクトで使われているConfigコンポーネントについて解説します。 Symfony ConfigコンポーネントConfigコンポーネントはソフトウェアの可変部分を表現する言語を定義し、処理するためのフレームワークです。Symfonyフレームワークにおいてはバンドルおよびその背後にあるコンポーネントの可変部分をユーザーが構成するために使われています。 Configコンポーネントが取り扱うのは一般的に設定や構成と呼ばれるものです。 設定はDSLである ドメイン固有言語 (DSL) は特定用途向けの言語です。ドメイン固有言語は、システムファミリの具体的なメンバを「発注」するのに使い、ゆえにジェネレーテ

    Pieceの中のSymfony #4: Configコンポーネント
  • Zend\Diを使ったDIの自動ワイヤリング

    「Pimpleでシンプルに正しくDIを理解する」の記事では、シンプルなDIコンテナPimpleにオブジェクトの依存関係の知識を集約する方法について解説しました。Pimpleの場合はサービスオブジェクトのファクトリーとして機能する無名関数の中に依存オブジェクトを記述しました。このように、実際に利用する依存オブジェクトを決めることをワイヤリングと呼びます。 今回は、ほぼ同一のオブジェクトモデルに対して、Zend Framework 2.0のDIライブラリ(Zend\Di)を使うように置き換えてみます。一般的にDIを扱う場合、依存関係の定義とワイヤリングのために何らかのコード―これは何らかの設定言語だったりプログラミング言語だったりします―を記述しなければならず、ある程度の規模以上のモデルクラス群をDIコンテナで管理する場合、定義のコーディング量がばかにならくなってきます。しかし、型を持ったプロ

    Zend\Diを使ったDIの自動ワイヤリング
  • Pieceの中のSymfony #3: Dependency Injectionコンポーネント

    Piece FrameworkのプロダクトのひとつStagehand_TestRunnerは、CLIでユニットテストを実行するための継続的テストランナーです。Stagehand_TestRunner v3の実装には多くのSymfonyコンポーネントが使われています。今回はStagehand_TestRunnerを動作させる上で重要な役割を果たしているDependency Injectionコンポーネントについて具体的な使い方を解説します。 Symfony Dependency InjectionコンポーネントDependency InjectionコンポーネントはSymfonyにおけるDIコンテナの実装であり、WebアプリケーションフレームワークとしてのSymfonyの基盤となるプロダクトです。サービスの依存性とその注入方法の定義、サービスの作成・取得、サービスへの依存性の注入、といったD

    Pieceの中のSymfony #3: Dependency Injectionコンポーネント
  • print_oで複雑な構成のオブジェクトグラフをビジュアライズする

    PHPにはvar_dump()という関数があり、階層構造を持つオブジェクト(オブジェクトグラフ)をテキスト表現にできます。この情報を、グラフィカルで直感的に分かりやすい形式で出力するためのユーティリティがprint_oです。@koriymさんが開発されています。 koriym/print_o An object graph visualizer for PHPprint_oのインストール方法print_oはPHPのライブラリとしては単独で利用可能です。Webブラウザへの描画用に外部のJavaScript/CSSを利用していますが、これらはGoogleGitHubホストされたファイルを読み込むようになっています。したがってインターネットに接続された環境であれば、print_o体のインストール以外に特別な手順は不要です。 たとえばcomposerを利用する場合は、composer.jso

    print_oで複雑な構成のオブジェクトグラフをビジュアライズする
  • Pimpleでシンプルに正しくDIを理解する

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

    Pimpleでシンプルに正しくDIを理解する
  • 帰ってきたまっつんチャレンジ #1: Play Framework

    こんにちは。 まっつんこと松藤です。 まっつんチャレンジとは?ITEMAN Blogで不定期連載していたまっつんチャレンジが、場所を移して約2年8ヶ月ぶりに再開することになりました。まっつんチャレンジとは、プログラミング言語や環境に関わらず技術的には大変興味深いけれど試すのが大変面倒くさそう難しそうなフレームワークやライブラリに私まっつんが挑戦し、それらがどんなものであるのかを私なりに皆様にお届けするシリーズです。 再開の第1回目はScalaのWebアプリケーションフレームワークPlay Framework 2.0です。 Play FrameworkはJavaScalaをネイティブサポートしたWebアプリケーションフレームワークです。非同期処理やNoSQLデータベースのサポートといった先進的な機能を備えているのですが、今回はルーティングやコントローラ、テンプレートといったWebアプリケー

    帰ってきたまっつんチャレンジ #1: Play Framework
    k-holy
    k-holy 2012/05/30
    久々のポテトバーガー注文アプリケーション
  • Practical Symfony #14: フォームでCollectionTypeを使う 第2回

    Symfony2のフォームでCollectionTypeを使う方法について、第1回ではエンティティクラスと対応付けたFormTypeクラスを作る部分を解説しました。作成したFormTypeは、以下のようにAnswerTypeとAnswerDetailTypeで親子関係を持っています。 今回は、フォームのレンダリングとFormViewについて見てみましょう。 デフォルトのレンダリングフォームにはデフォルトのレンダリングエンジンがあり、FormTypeで定義したウィジェットを階層構造も含めて手軽にレンダリングすることができます。コントローラでテンプレートをレンダリングする時に‘form’ => $form->createView()のようにしてFormViewインスタンスをformという変数名で渡している場合、テンプレート側では{{ form_widget(form) }}とするだけで、このフ

    Practical Symfony #14: フォームでCollectionTypeを使う 第2回