Shin x Blog

誰のためのソースコード?

2020-01-22T10:00:00+09:00

「誰のためのデザイン?」の旧版と改訂・増補版を読みました。

以前に旧版を読んだのですが、その記憶もあやふやなくらい前だったので、あらためて読み直し、その面白さゆえに改訂・増補版も購入してこれも読み終えました。

Web システム開発を生業としているので、日々ユーザとのインタラクションが発生するプロダクト開発に関わっているわけで、ユーザがどのように製品を認知し、使うかという内容は参考になりました。

それとは別にソフトウェア開発という観点で、ソースコードを読む時に人がどのように認知するのかという点でも興味深いものでした。このエントリでは、自分なりに整理したソースコードと概念モデルについて残しておきます。

ソースコードとメンタルモデル
ソースコードの概念モデル
誰のためのソースコード?
さいごに
メモ

ソースコードとメンタルモデル

ある程度、経験のあるプログラマであれば、ソースコードを見るだけで想起されるイメージがあります。例えば、for を見れば繰り返しを思い浮かべるでしょうし、if を見れば条件分岐を思い浮かべるでしょう。これは、読み手自身にコードを理解するメンタルモデルが存在するからです。

for や if を文と見るか、式と見るかは書かれたプログラミング言語が何か、またそのメンタルモデルを持つかどうかによります。Scala のように for に繰り返し以外の動作がある言語もあります。こうしたものは、前提となる知識を理解しておかないと読む手は理解できません。

object Sample extends App {
  val s = for {
    i <- Some(1)
    j <- Some(2)
  } yield (i + j)

  println(s) // Some(3)
}

デザインパターンを利用したコードは、その概念モデルを理解している読み手に対してはコードの理解を助けます。しかし、そうではない場合、ただ冗長で理解しづらいコードのように映るかもしれません。

つまり、ソースコードを理解するには、コードの概念モデルと読み手のメンタルモデルが一致する必要があります。

ソースコードの概念モデル

ソースコードには書き手の概念モデルが反映されます。この概念モデルと読み手のメンタルモデルが一致する、もしくは読み手が理解できれば、ソースコードの内容を把握して利用できます。読み手はソースコードの概念モデルを理解することが重要です。

ソースコードが持つ概念モデルは「実行モデル」「プログラマモデル」「ユーザモデル」の3つに分けられると考えました。

実行モデル

実行モデルは、コンピュータがソースコードを解釈し、実行する（実行可能な状態にする）ためのモデルです。多くの場合、コンパイラやランタイムの概念モデルといえます。これ理解できなければ、コードがどのように動作するのかをイメージできません。このモデルは一般的なもので、プログラミング言語のマニュアルや技術書などで広く公開されています。同じ言語やプラットフォーム、フレームワークなどでは同じモデルとなるので、一度学習すれば他のソフトウェアでも流用できます。また、実際に実行したり、自動テストを実行するなどで検証が比較的容易です。

プログラマモデル

プログラマモデルは、プログラマがソースコードを理解するためのモデルです。分かりやすい変数名を付ける、関数やクラス構造に分ける、デザインパターンを適用する、レイヤ分けなどのアーキテクチャを構成するなどです。いわゆる可読性、保守性の高いコードを書くためのモデルです。これは、読み手のメンタルモデルによって、理解しやすいかは変わってきます。我々は、書籍「リーダブルコード」や「Effective XXX」のような情報で共通認識を持っているので、それを理解している人であればそれに従うことで同じモデルを利用できます。しかし、そうではないメンタルモデルを持つチームでは、また異なるモデルをコードで表現する必要があります。

ユーザモデル

ユーザモデルは、ソフトウェアを利用して実現したい機能や対象とするドメインなどを示すモデルです。要求モデルやドメインモデルといったものです。重要なモデルですが、ソースコード自体にこのモデルが反映されているかは実装次第です。ソースコードのみから読み取るのが難しい場合も多く、ドキュメントや口頭による説明など他の手段で共有します。

ユーザモデルは問題領域のモデル、実行モデルとプログラマモデルは解決領域のモデルともいえます。

誰のためのソースコード?

ソースコードを理解するには、ソースコードと読み手のメンタルモデルが必要になります。よく「可読性の高いコード」という表現をしますが、可読性を決めるのはソースコードだけではなく、読み手のメンタルモデルも大きく影響します。

これは大切な視点で、特にプロダクションコードであれば、同じチーム外の人が理解する必要はなく、一般的にはリーダブルコードで無くても、その特有の概念モデルが共有できれていれば良いという考え方もできます。もちろん、後から入る人の事も考えて、一般的な書き方にしておく方が得策です。しかし、すでにそうではないコードがある場合、コードを直す以外にチームへの概念モデル共有をしっかりやるという方法も考えられるということは一つの考え方として認識しておくと良いでしょう。

デザインパターンや戦術的 DDD パターンが良いと聞いて、自分たちのソフトウェアに反映しようとしても中々うまくいかない、自分は理解できるがメンバーには理解されないということもパターンの概念モデルと各自が持つメンタルモデルの齟齬によって起こると言えます。

さいごに

ソースコードは、コンピュータをどう動かすかということを示すものですが、これを書くのも読むのも人です（今のところ）。つまり、人がソースコードをどう理解するのかという視点はソフトウェア開発の現場では重要なことです。自分の中で課題として考えていたことが、こうした視点で本書を読むことで、ある程度整理することができました。

他にも多くのインスピレーションを与えてくれる本なので、これからも何度となく開くことになるでしょう。願わくば、いつでも読めるように電子書籍版を発売してほしいところです。

人は勝手に独自のストーリーを描く生き物なので、本書を読んでも、このエントリを読んでも、あなたが持つメンタルモデルによって、また異なるイメージを描くでしょう。うまく私の概念モデルが伝わると良いのですが。

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

作者:ドナルド・A. ノーマン,D.A. ノーマン
出版社/メーカー: 新曜社
発売日: 1990/02/01
メディア: 単行本

誰のためのデザイン？　増補・改訂版　―認知科学者のデザイン原論

作者:D. A. ノーマン
出版社/メーカー: 新曜社
発売日: 2015/04/23
メディア: 単行本

メモ

学習された無力感、教えられた無力感
行動遂行のサイクル
- ゴール、意図の形成
- 行為の詳細化
- 行為の実行
- 外界の状況の知覚
- 外界の状況の解釈
- 結果の評価
ポジティブな情動、ネガティブな情動
ヒューマンエラーではなくデザインエラー
ポジティブ心理学
短期記憶、長期記憶、外部記憶
- 短期記憶=スタック、長期記憶=ヒープ、外部記憶=ストレージに例えられる
- [旧版] 三目並べのデシジョンツリー。浅いか or 狭いものが分かりやすい
デザインにおいて成功の秘訣は、何が本当の問題かを理解すること
漸進的なイノベーションは毎年何百万も起こるが、急進的なイノベーションは遥かに少ない。
- 急進的なイノベーションを求めがちだがそれには時間がかかる。漸進的なイノベーションを積み重ねるのも大切。
認知と情動。本能レベル、行動レベル、内省レベル
- 例: ブランドイメージや利用経験によるプラスの内省的な情動により、使いにくさや悪い経験といったマイナスの情動を覆す
- スパゲッティコードを見ると、本能レベル or 行動レベルでマイナスの情動を引き起こす？
エラー
- スリップとミステイク
- スリップの型
高次の記述と低次の詳細記述
強制選択機能
スイスチーズメタファー
人間中心デザイン（HCD）
- 反復サイクルは、アジャイルやリーンスタートアップと同様（本文にも書かれている）

「Kubernetes で構築する PHP 開発環境」を発表しました

2019-12-06T12:22:59+09:00

2019/12/01 に東京で行われた PHP Conference Japan 2019 - #phpcon にて、「Kubernetes で構築する PHP 開発環境」を発表してきました。

発表資料

サンプルコード: https://github.com/shin1x1/laravel-k8s-dev-sample
Togetter: https://togetter.com/li/1438089

Kubernetes を使って、PHP 開発環境を構築するという内容でした。デモでは、Mac に構築した Kubernetes クラスタを紹介して、Mac にあるソースコードを変更すると、Kubernetes クラスタ内で実行している PHP Pod で読み込めるということを紹介しました。PHP 開発では重要なことですね。

開発環境に特化した内容なので、本番等で使うときはまた違う点がありますが、いずれ開発環境を構築する際に参考になれば嬉しいです。

サンプルコードでは、Makefile を用意しているので、Kubernetes を自分の PC で動かしてみるサンプルとしても使えると思います。Docker Desktop の Kubernetes 機能を Enable にして試してみて下さい。

セッション前に参加者の方に挙手でアンケートを取ったのですが、Kubernetes を使っている方はわずか 10 人程度でした。実際のところは、まだまだ使われていないんだなあということと、それにも関わるず聞きに来られた方が多くいたということでその関心の高さもうかがえました。

Kubernetes on CircleCI による CI

元々の資料には入れていたのですが、時間の関係で発表前に削除したのが、この CI に関する部分です。公開資料には追加していますので、興味がある方は資料をご覧ください。 https://speakerdeck.com/shin1x1/php-development-environment-on-kubernetes?slide=26

CircleCI + Kubernetes の組み合わせで情報を探していると、Kubernetes クラスタは、GKE や EKS など外部にあって、それを CircleCI の中から、kubectl 等で操作するというパターンは多いのですが、CircleCI の中で Kubernetes を動かすというものは少なく、色々と試行錯誤を行いました。

基本は、minikube なり kind なりを入れれば良いという話なのですが、なぜか kubectl apply が失敗したり、クラスタ起動が遅かったりで、動くけど、まだまだ改善の余地があるというが今の印象です。

CircleCI 側で Kubernetes 環境が用意されていて、CI 時によしなに利用できるようになると嬉しいですね。

このあたり、みんながどうしているか聞いてみたいところです。

対話

自分のセッションがあるイベントでは、あまり他の方の発表は聞けないことが多いのですが、今回は前日にも発表があったこともあり、セッションに参加してもいまいち集中できなかったので、うろうろしながら、色々な方と話していました。

いつもはあまりいないスタッフ、スピーカー控室（和室）でゆっくりして、周りにいた方とお話ができたのも楽しかったです。場所自体がカンファレンスの喧騒からは切り離されたところなので、落ち着いて話ができるのが良かったです。

本当は、もっと話したい方もいたし、これまで接点が無かった方とも話してみたかったのですが、どうにも時間も体力も足りませんでした。またの機会にお願いします！

最近は、PHPの現場をやっているおかげで、配信した内容が会話のネタになったり、ゲスト出演の依頼が話しかけるきっかけにもなったりしています。何人かの方に承諾して頂けたので、来年の収録が楽しみです。

さいごに

前日は PHPerKaigi（派生イベント）、当日は PHP カンファレンスということで、両イベントのキャラクタが違いが感じられました。PHPerKaigi は、参加者同士が交流しやすくする仕掛けが多く用意されてあり、主催側がそれを促していること。一方、PHP カンファレンスは、場は用意するので、あとはご自由にという印象でした。

もちろん、どちらが良い悪いという話ではなく、また規模感も参加費も何もかもが違うので単純には比較できないですが、2 日間で異なる雰囲気のイベントに登壇したので、その対比が面白かったです。

毎年ながら、あの規模のイベントをつつがなく運営されているのは本当にありがたい限りです。今年も楽しいカンファレンスをありがとうございました！

「独立したコアレイヤパターンの適用 - fortee 編 -」を発表しました

2019-12-06T09:19:42+09:00

2019/11/30 に東京で行われた大改修！PHPレガシーコードビフォーアフターにて、「独立したコアレイヤパターンの適用 - fortee 編 -」を発表してきました。

発表資料

サンプルコード: https://github.com/shin1x1/independent-core-layer-pattern-fortee-demo
Togetter: https://togetter.com/li/1438084

オーガナイザの @tomzoh さんが開発、運用されている fortee.jp というカンファレンス運用サービスのソースコードに独立したコアレイヤパターンを適用するという内容です。

最初にコアレイヤパターンについて解説をした後、ライブコーディングで実際のコードに対してパターンを適用するデモを行いました。

100 人でやるモブプロ

コードの解説をしながら、ライブコーディングを進めていくわけですが、書きながら、あれ？PhpStorm の警告が出てままになっているなと思ったら、会場から指摘して頂いて気づくということが何度かありました。（特に @hamaco さん。感謝 m(_ _)m）

ライブコーディングは、コードを完成させることも大事ですが、それより、書いていく過程をみんなで共有するというのがポイントだと思います。より伝わるというのは、セッション後にいただいたフィードバックでも感じられたので、今後も機会があればやっていきたいです。

当日は雰囲気が良くて、みんなに見られるというより、見守られながら、壇上でコードを書くのはとても楽しかったです。ありがとうございました。

なお、引数の uuid などを ValueObject にしないのですか？という質問がありましたが、今回はコアレイヤパターンの適用が目的だったこと、また漸進的に少しづつ適用することを示したかった、そして時間が厳しかったので行いませんでした。普段なら作るので、ツッコミたくなるのはすごく分かります :)

PhpStorm

ライブコーディング中は、コードを書いて話すことに集中していたので、あまり気が付かなかったのですが、後で Twitter を見返すと、PhpStorm の操作に関するフィードバックが多かったことに驚きました。IDE を使い、さらに型を適切に付けていくことで、リズム良くコードが書けることが共有できて良かったです。

昔、Vim をメインに開発していた頃、とある勉強会で Eclipse による Java のライブコーディングを見て、それがまるで魔法のようにコードができあがっていくのに感動したことがありました。それでも、IDE を使い出したのは、さらに数年後になるわけですが、そんな自分が、IDE の使い方で驚かれるというのは不思議な感覚です。ああ、気がつけば、ある程度使えるようになってるんだなあと。

翌日に PHP カンファレンスがあったのですが、このデモを見て、サムライズムさん（ JetBrains 公式パートナー）のブースに足を運んだ方もいたみたいです。PhpStorm 良いツールですね。

Vim 派の方が、PhpStorm に惹かれるといった意見もいくつかありました。自分も Vim から PhpStorm に移ったタイプなので*1、IdeaVim （JetBrains IDE 用 Vim エミュレータプラグイン）を入れて、ぜひ PhpStorm 試してみて下さい。

独立したコアレイヤパターン

当日も、翌日の PHP カンファレンスでも、コアレイヤパターンに関する質問を受けることが何度かありました。中には実践している方もいて、その中でどう活用するか、特定のケースでどのように考えるかといったお話もありました。色々な人の考えを聞くことで、より立体的にこのパターンを見ることができ、とても勉強になりました。

話題としては下記のようなものでした。

共通するロジックやポートをどう共通化するか
どの箇所に適用するか、しないか
- Query と Command
- ビューに関する読み込み
実際のユースケースでの構造
こうした構造のメリットをどう理解してもらうか

こうしたイベントでお話を聞いていると、ベースのアイデア自体は少しづつ理解して頂けることが増えた印象なのですが、いざ実践したり、実践を想定してご自身の現場への導入を考えた際にどうすれば良いのだろうという内容が出てきました。

まずは、ベースのアイデアを理解してもらおうと、これまで単純なユースケースでの実装例を公開していたのですが、もう少し実践よりのコードがあってもいいかなとも考えています。

また機会があれば、養殖物ではなく、天然物のコードに適用するデモができると良いですね。

さいごに

他の方のセッションでは、それぞれの視点で改善点を解説されていて、私が fortee のコードを見ていたということもありますが、そのどれもが面白く、聞きながら良いイベントだなあと嬉しくなりました。TL やアンケートを見ていても、参加された方も楽しんで頂けたようで、良かったです。

公開を前提とせずに、自分が書いたコードを人前でネタにされて、あれやこれや言われるのはなかなか勇気がいることだと思います。当然、書いた状況やコンテキストがあるわけで、後で冷静に考えれば、自分でもそうは書かないということがあったりもしたと思いますが、言い訳もせずに快くコードを差し出してくれた長谷川さんに感謝です。良いイベントをありがとうございました！

*1:Vim は今も使ってます

関数型言語で DDD - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

2019-08-20T08:30:00+09:00

オブジェクト指向言語でドメインモデルを実装することが当然のように行われていますが、Go で開発したり、Haskell で遊んだりしている中で、他のパラダイムの言語で実装するのはどうなんだろうかという想いがありました。

そんな時に出会ったのが、Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# という本です。

概要
構成
ドメインを理解し、モデリングする
端的なフレーズ
Database-Drive-Design や Class-Driven-Design との違い
型、型、型
関数型言語による実用例
恐怖のモナド
さいごに
参考

概要

本書は、とある会社の受注とその関連業務をドメインとし、モデリングして、実装していくという内容です。紙ベースで行われている業務を Web システムにしていきます。

オブジェクト指向言語を対象とした書籍は、エリック・エヴァンスの DDD 本をはじめ、いくつかありますが、この本では、関数型言語である F# で実装するのが特徴です。関数型言語で実装するということは、モデリングにも影響を及ぼすことになります。関数型言語で、どのようにドメインをモデリングし、現実的なコードに落としていくのかというというのが読む前の関心でした。

なお、サンプルコードなどは、F# で実装はされていますが、固有の記述は少ないですし、F# 特有の機能はちゃんと解説があるので、特に問題無く読めました。

構成

書籍は、「Understanding the Domain」「Modeling the Domain」「Implementing the Model」の 3 部で構成されています。全体を通じて、同じ業務プロセス（主に受注業務）について、ドメインの理解、モデリング、実装と進んでいくので、DDD を実践する流れが掴みやすいです。個人的には、受注業務というイメージしやすいドメインが対象というのも良かったです。

3 部の最後にある「Evolving a Design and Keeping It Clean」は、これまでのデザインや実装をベースに仕様変更に対して、どのように対応していくかという内容なので、全てのパートに関連するところなので、第 4 部かなという気がしますが、ボリューム的に 3 部におさめたように感じました。

1. Understanding the Domain
  * Introducing Domain-Driven Design
  * Understanding the Domain 
  * A Functional Architecture
2. Modeling the Domain
  * Understanding Types 
  * Domain Modeling with Types 
  * Integrity and Consistency in the Domain
  * Modeling Workflows as Pipelines 
3. Implementing the Model
  * Understanding Functions 
  * Implementation: Composing a Pipeline 
  * Implementation: Working with Errors
  * Serialization 
  * Persistence
  * Evolving a Design and Keeping It Clean

ドメインを理解し、モデリングする

読む前は、関数型言語による DDD 実装を示すといった内容をイメージしていたのですが、タイトルのとおり、いかにドメインを理解して、モデリングしていくという内容が半分以上占めています。

はじめに、Event Storming やインタビューから要求を聞き出して、対象ドメインの発見、そして理解を深めていきます。問題領域にあるドメインをサブドメインに分割し、解決領域に境界づけられたコンテキストとして定義します。さらにコンテキスト間の関係をコンテキストマップで示します。

これで全体像を把握した後に、対象業務のワークフローを題材に必要なドメインを F# の型としてモデリングを進めていきます。各要素の型を組み合わせて、ワークフローのサブステップを関数とし、さらに関数を合成してワークフローを組み上げていきます。

これらの流れが一気通貫で解説されており、対象ドメインがイメージしやすく、また小さな規模の話ということもあって、関数型言語云々は関係無く、とても分かりやすかったです。

端的なフレーズ

DDD や関数型言語に関する知見を短い文で端的に示している箇所がいくつかあり、内容を理解したり、考えを整理する上でとても役立ちました。記憶にも残りやすくて良いですね。

例えば、下記のような感じです。

共有モデルを作るガイドライン。
- データ構造ではなく、ビジネスイベントやワークフローに注目する。
- 問題領域では、ドメインを小さなサブドメインに分割する。
- 解決領域では、サブドメイン毎にモデルを作る。
- プロジェクトに関わる全ての人で共有され、コードでも利用される共通の言語（ユビキタス言語）を作る。
問題を理解することは、安易に解決策を作ることではない。
まず、ビジネスイベントに注目する。
persistence ignorance*1
make illegal states unrepresentable

Database-Drive-Design や Class-Driven-Design との違い

Domain-Driven 以外の設計方法として、Database-Driven や Class-Driven な方法との違いについても書かれています。データベーステーブルから設計しないということは良く言われているとは思いますが、Class-Drivenについては、やや例示されている内容が恣意的な面もあり、まあそういう見方もあるかなという程度でした。

いずれにしても、ドメインを理解するフェーズにおいては、システムに関する技術要素を入れないようにするという点は共通のものですね。

型、型、型

対象ドメインについて、とにかく型で表現していきます。代数的データ型の表現力のおかげで、簡潔な記述でドメインが型として表現でき、コンパイラでチェックができるのは良いですね。この簡単に型が書けるというのは、数多くの型を作る上で一つのポイントだと思います。*2

対象ドメインの受注業務では、注文の状態が「未処理」「未検証」「検証済」「価格算出済 or 無効」といった具合に遷移していきます。状態の管理ということで、ステートマシンの話になるのですが、ここでは、それぞれの状態を別の型にして、これを Choise Type にしています。

type Order = 
  | Unvalidated of UnvalidatedOrder
  | Validated of ValidatedOrder
  | Priced of PricedOrder
  // etc

型を分けておけば、状態によって必要なフィールドが異なっていても、それぞれの型で定義すれば良く、無駄なフィールドを持つ必要が無くなります。このような手法を make illegal states unrepresentable*3 と呼ぶようです。

この値を利用する関数では、パターンマッチによって状態毎の処理を記述します。OOP なら、State パターンで表現できそうですが、この場合、State クラス（とその派生クラス）側で実装を持つ形になります。このあたりは、FP と OOP で表現が異なるので面白いところですね。

こうした箇所はいくつもあり、例えばメールアドレスが未検証か検証済かなども別の型で定義して、Choice Type でまとめられています。

とにかく型で表現していくので、「型を大量に作るけど、本当に必要？」という読者の懸念にも触れられていて、必要に応じて減らして下さいとも書かれています。このあたりは現場での導入も考慮されているなと感じました。

関数型言語による実用例

ワークフローを実装する箇所では、必要なサブステップを関数にして、それを合成していきます。合成するにあたって、関数の出力と次の関数の入力の型が合わない箇所への対応についても解説されています。アダプタ関数やモナドを使って、とにかく合成していくというのは関数型らしいです。

また、部分適用による DI も興味深かったです。関数を元に新しい関数を作って、というのは理解はしていたのですが、永続化処理を行う関数をトップレベルで部分適用して、内包した関数をワークフローに渡すというのは、実用例として分かりやすかったです。OOP でいうと、コンストラクタインジェクションで IO 操作を与えておけば、生成されたインスタンスを使う側はそれを意識せずに使えるというのと同じですね。

なお、本書では、ドメインに関する実装だけではなく、データベースアクセス処理や外部システムとの連携（DTO とドメインモデルの相互変換）についても解説されており、関数型言語をビジネスアプリケーションで利用する上での実例として参考になりました。

恐怖のモナド

エラーハンドリングの章では、モナドを活用にしたモナディック関数の合成についても触れられています。the scary-sounding monad と表現されていて、やっぱり、そういう扱いなんですね ;)

本文では、モナドに関する解説無しに実際のコードに適用した後に、モナドについての説明が入ります。下記の文は、端的に表現されていてイメージしやすいです。

A monad is just a programming pattern that allows you to chain “monadic” functions together in series. OK, then what’s a “monadic” function? It’s a function that takes a “normal” value and returns some kind of “enhanced” value. In the error-handling approach developed in this chapter, the “enhanced” value is something wrapped in the Result type, so a monadic function is exactly the kind of Result-generating “switch” functions that we’ve been working with.

さいごに

DDD と関数型言語による身近な題材による実装テクニックが平易な解説で学べるという、一粒で二度美味しい良い本でした。ドメインの定義やモデリングについては、これまで読んだ本の中で一番イメージしやすかったです。

この本で、日頃自分が開発している領域についても関数型言語を利用するイメージができました。OOP による DDD の情報が多いですが、もしかすると関数型言語の方が平易に DDD を実装できるのはないかという印象すら持っています。

関数型言語に興味が無い人も、DDD による設計と型による表現は学ぶべきものがあると思うので、おすすめです。

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

作者: Scott Wlaschin
出版社/メーカー: Pragmatic Bookshelf
発売日: 2018/02/04
メディア: ペーパーバック
この商品を含むブログを見る

下記なら、eBook が DRM フリーです。 pragprog.com

参考

関数型DDD〜Domain Modeling Made Functional まとめ - Qiita

*1:blessed ignorance から来てる表現？

*2:PHP でも、代数的データ型とパターンマッチが欲しい。。。

*3:https://blog.janestreet.com/effective-ml-revisited/

Laravel におけるリポジトリ実装のポイント

2019-06-21T08:08:00+09:00

Laravel を使った開発でも、ドメインロジックと RDBMS などの永続化層へのアクセスを分離するためにリポジトリパターンを採用するケースが増えてきました。

ただ、Laravel には Eloquent という Active Record タイプの ORM があるので、これとリポジトリをどのように組み合わせるかで悩んでいる人が多いようで、これまで開発現場や勉強会などで質問を受けることがありました。

本エントリでは、リポジトリを実装してきた経験を元に、私が考える実装のポイントをご紹介します。

1. ドメインデータの入出力にリポジトリパターンを使う
2. メソッドの型宣言にドメインデータを指定する
3. 機械的に CRUD メソッドを実装しない
4. Eloquent を利用したリポジトリクラスの実装
5. 複数テーブルを扱うリポジトリ
6. Paginator との連携
さいごに

1. ドメインデータの入出力にリポジトリパターンを使う

リポジトリパターンは、ビジネスロジックの実行に必要なデータを RDBMS のようなデータストアから入出力する際に利用します*1。あくまで起点となるのはドメインデータです。

本エントリでは、ビジネスロジックの実行に必要なデータを、DDD で登場する Entity や Value Object、Aggregate などのドメインモデルはもちろんのこと、stdClass や array、 string、int などの組み込みの型も含める意図で、ドメインデータと呼びます。

Eloquent のような Active Record では、1 テーブルにつき、1 クラスといった具合にテーブルを写すものとして実装しますが、リポジトリはそうではありません。一つのテーブルから複数のリポジトリが実装される場合もありますし、複数のテーブルを集約したリポジトリを実装することもあります。

ドメインデータの入出力のためにリポジトリを使うという点をまず意識します。

2. メソッドの型宣言にドメインデータを指定する

リポジトリのインターフェイスは、1. を意識して定義します。このインターフェイスでは、ドメインデータの入出力を示すので、メソッドの引数や戻り値では、ドメインデータを型として指定します。つまり、Eloquent を引数にしたり戻り値にしたりはしないということです。

下記では、UserRepository という User モデルの入出力を担うリポジトリインターフェイスを定義しています。この User は、POPO(Plain Old PHP Object) で実装したドメインデータであり、Eloquent ではないので注意して下さい。

findById メソッドでは、UserId クラス $id を引数に取り*2、User モデルを返しています。store メソッドでは、User モデルを引数に取ります。

このインターフェイスを見れば、User モデルに関するリポジトリであることは分かりますが、実際にどのような方法でデータストアへアクセスして入出力を行うのかは分かりません。リポジトリをドメインデータの入出力を行うものとして捉えれば、これで十分なわけです。

<?php

namespace Acme\Domain\Repository;

use Acme\Domain\Model\User;
use Acme\Domain\Model\UserId;

interface UserRepository
{
    /**
     * @param UserId $id
     * @return User
     */
    public function findById(UserId $id): User;

    /**
     * @param User $user
     * @return UserId
     */
    public function store(User $user): UserId;
}

3. 機械的に CRUD メソッドを実装しない

先に書いたとおり、リポジトリはドメインデータの入出力を行うものです。つまり、ドメインデータとして必要な入出力のみを定義すれば良いのです。アプリケーションに、あるドメインデータを削除する概念が無いのなら、remove メソッドは不要です。読み取る際も、ID がキーなのか、Email なのか、複数の条件なのかはドメインデータによって様々です。

また、結果としては同じ users テーブルに対する保存であっても、上記の UserRepostitory::store メソッドのようにモデルをそのまま永続化するメソッドがあったり、ユースケースによってはメールアドレスだけを保存するメソッドがあっても構わないということです。

機械的に CRUD を付けるというのは、データベーステーブルに対応するリポジトリを実装するという発想から来るものでしょう。そうではなく、リポジトリでは、対象のドメインデータが永続化層にどのような操作が必要かを考えて、それのみを実装すると良いです。

4. Eloquent を利用したリポジトリクラスの実装

リポジトリのインターフェイスさえ決まれば、後の実装は簡単です。インターフェイスの定義を満たすように実装していくだけです。

下記では、UserRepository インターフェイスを Eloquent を使って実装しています。EloquentUser は、users テーブルに対する Eloquent です。findById メソッド、store メソッド共に、この EloquentUser を使って実装しています。

findById メソッドでは、EloquentUser を使って、レコードを取得し、その結果を User モデルにセットして返しています。

store メソッドでは、User モデルを引数に取っており、必要な EloquentUser インスタンスにセットして保存しています。

このようにドメインデータを入出力に使うようにインターフェイスを定義しておけば、その実装に Eloquent を利用しても、それはあくまでリポジトリクラス内部の実装方法に過ぎず、何ら問題ありません。

<?php

namespace Acme\Infrastructure\Repository;

use Acme\Domain\Exception\NotFoundException;
use Acme\Domain\Model\User;
use Acme\Domain\Model\UserId;
use Acme\Domain\Repository\UserRepository;
use Acme\Infrastructure\Eloquent\EloquentUser;

final class EloquentUserRepository implements UserRepository
{
    /** @var EloquentUser */
    private $eloquentUser;

    /**
     * @param EloquentUser $eloquentUser
     */
    public function __construct(EloquentUser $eloquentUser)
    {
        $this->eloquentUser = $eloquentUser;
    }

    /**
     * @param UserId $id
     * @return User
     * @throws NotFoundException
     */
    public function findById(UserId $id): User
    {
        /** @var EloquentUser $eloquent */
        $eloquent = $this->eloquentUser->newQuery()->find($id->asInt());
        // Facade を使っても構わない
        // $eloquent = EloquentUser::find($id->asInt());
        
        if ($eloquent === null) {
            throw new NotFoundException('user not found:' . $id);
        }

        return new User(
            new UserId($eloquent->id),
            $eloquent->name,
            $eloquent->email
        );
    }

    /**
     * @param User $user
     * @return UserId
     */
    public function store(User $user): UserId
    {
        if ($user->hasId()) {
            $eloquent = $this->eloquentUser->newQuery()->findOrFail($user->getId()->asInt());
        } else {
            $eloquent = $this->eloquentUser->newInstance();
        }

        $eloquent->name = $user->getName();
        $eloquent->email = $user->getEmail();
        $eloquent->save();

        return new UserId($eloquent->id);
    }
}

5. 複数テーブルを扱うリポジトリ

これまで述べたとおり、リポジトリはテーブルと 1 対 1 で実装する必要はありません。つまり、複数テーブルからデータを取得して、一つのドメインデータとして返す場合もあります。

下記は、PointEmail モデルを取得する PointEmailRepository です。findByUserId メソッドで PointEmail モデルを取得します。このインターフェイスでは、どのテーブルのどのカラムから値を取得するかは分からず、また知る必要もありません。分かるのは、UserId を渡せば、PointEmail が返ってくるということだけです。

<?php

namespace Acme\Domain\Repository;

use Acme\Domain\Model\PointEmail;
use Acme\Domain\Model\UserId;

interface PointEmailRepository
{
    /**
     * @param UserId $id
     * @return PointEmail
     */
    public function findByUserId(UserId $id): PointEmail;
}

PointEmail をデータベースから取得するには、users.email と user_points.point が必要となります。これを実装しているのが、下記の EloquentPointEmailRepository です。findByUserId メソッド内では、テーブルを join してレコードを取得し、それを PointEmail インスタンスとして返しています。

このように複数テーブルから値を取得する際もレコードを取得して、ドメインデータにセットして返せば良いのです。

もし、ドメインデータに必要な値のデータソースが異なる場合、例えば、データベースにある値と Redis にある値が必要な場合でも理屈は同じです。リポジトリインターフェイスでは、ドメインデータを返す定義を書いておき、それぞれのデータソースからの取得処理はリポジトリクラスで書けば良いのです。

<?php

namespace Acme\Infrastructure\Repository;

use Acme\Domain\Exception\NotFoundException;
use Acme\Domain\Model\PointEmail;
use Acme\Domain\Model\UserId;
use Acme\Domain\Repository\PointEmailRepository;
use Acme\Infrastructure\Eloquent\EloquentUser;

final class EloquentPointEmailRepository implements PointEmailRepository
{
    /** @var EloquentUser */
    private $eloquentUser;

    /**
     * @param EloquentUser $eloquentUser
     */
    public function __construct(EloquentUser $eloquentUser)
    {
        $this->eloquentUser = $eloquentUser;
    }

    /**
     * @param UserId $id
     * @return PointEmail
     * @throws NotFoundException
     */
    public function findByUserId(UserId $id): PointEmail
    {
        $record = $this->eloquentUser->newQuery()
            ->join('user_points', 'user_points.user_id', '=', 'users.id')
            ->where('id', $id->asInt())
            ->first(['email', 'point']);

        if ($record === null) {
            throw new NotFoundException('PointEmail not found:' . $id);
        }

        return new PointEmail(
            $record->email,
            $record->point
        );
    }
}

これはデータストアへの保存についても同じです。一つのドメインデータを複数テーブルに保存する場合も良くありますが、その時はリポジトリの中でトランザクションを開始して、各テーブルにデータを保存した後にコミットすると良いでしょう。もちろん、ケースバイケースにはなりますが、ドメインデータを入出力するリポジトリという視点ではこれがやりやすいです。

6. Paginator との連携

Laravel は、Eloquent との連携で便利に使える機構があります。例えば、Paginator はその一つでしょう。Eloquent を使えば、paginate メソッドで簡単にデータベースから必要な値を取得して、ビューに渡す Paginator インスタンスを生成できます。

一方、リポジトリを実装した場合、Eloquent はリポジトリの中で閉じており、戻り値にはドメインデータが返されるのでこうした機構が利用できないように見えます。

実は、Paginator は、データベースへのアクセスと Paginator の処理は独立しており、下記のようなコードで任意のデータに対して Paginator インスタンスを生成できます。つまり、総件数の算出やデータの抽出はリポジトリで行って、後は Paginator（下記では、LengthAwarePaginator ）インスタンスに与えるだけです。

これをビューファイルに渡せば、ページングなどに必要なリンクを blade で出力できます。

<?php

namespace Acme\Application\Action;

use Acme\Application\Repository\UserPaginatorRepository;
use Illuminate\Pagination\LengthAwarePaginator;
use Illuminate\Pagination\Paginator;

final class UserListAction
{
    private const PER_PAGE = 10;

    public function __invoke(UserPaginatorRepository $repository)
    {
        $page = Paginator::resolveCurrentPage();
        
        // リポジトリで総件数と 1 ページ分のデータを取得
        $total = $repository->count();
        $results = $repository->findUserList($page, self::PER_PAGE);

        // LengthAwarePaginator インスタンスの生成
        $paginator = new LengthAwarePaginator($results, $total, static::PER_PAGE, $page);

        return view('users.list', [
            'paginator' => $paginator,
        ]);
    }
}

もう一つの考え方としては、本エントリの趣旨からはずれますが、Paginator はビュー（プレゼンテーション）の関心事なので、Eloquent を生で使って実装するという方法もあります。このあたりは、何を目的にリポジトリを使うのかという観点で検討すれば良いでしょう。

さいごに

リポジトリの実装では、どのようにリポジトリインターフェイスを定義するかが肝になります。これが上手くいけば、後はそれを満たす実装を書くだけなので、迷うことは少なくなります。

本エントリのように、ドメインデータを引数や戻り値に指定するインターフェイスを書けば、リポジトリクラスでは、インターフェイスに沿って、データストアからデータを取得して、目的のデータ構造で返すだけなので、極論を言えば、Eloquent で実装しようが、Query Builder で実装しようが、Doctrine で実装しようが、それは実装の詳細に過ぎないということが分かるでしょう。*3

Laravel には、標準で Eloquent と Query Builder という強力な DAO が備わっているので、それらを活用したい人は多いでしょう。これまで示してきたように、Eloquent を利用してリポジトリを実装することは何ら問題無いので、上手く活用していきましょう。

*1:理想は、入出力すら意識せずに操作できることですが、実際のところ入出力であることは意識して実装することが多いです。

*2:int のような組み込みの型でも構いません。

*3:もちろん、実装の詳細は重要なので、データストアへのアクセスをどう実装するのが良いかというは視点では十分に検討する必要があります

rerun - コマンドが終了したら自動で再実行するツールを作りました

2019-05-29T00:00:00+09:00

rerun というコマンドランナーを Go で書きました。rerun を使って、コマンドを実行すると、コマンドが終了した際に再実行してくれます。systemd や supervisord の簡易版と言えばイメージしやすいかもしれません。

github.com

動作イメージ
動機
rerun
インストール
さいごに

動作イメージ

下記では、rerun で sample.sh が終了する度に再実行しています。

動機

Kubernetes クラスタを Mac 上の Docker Desktop 環境で開発している際、実行状況が分かるように、いくつかのログをターミナルで出力していました。例えば、kubectl get events -w などです。ただ、開発中に Docker Desktop が落ちることがあると、kubectl get events も一緒に終了してしまうので、Docker Desktop に合わせて、それらもいちいち起動し直すのが面倒でした。

そこで、こうした手間を省くために作ったのが、rerun です。

rerun

rerun コマンドの後に実行したいコマンドを指定します。rerun を実行すると、指定したコマンドを実行します。もし、コマンドが終了した場合、一定秒数経過後（デフォルト: 10s）に再びコマンドを実行します。

# sample.sh が終了したら、10 秒後に再実行
$ rerun ./sample.sh

-s オプションで、再実行までの秒数を指定できます。

# sample.sh が終了したら、1 秒後に再実行
$ rerun -s 1 ./sample.sh

実行したいコマンドにハイフン - が含まれる場合は、コマンドの前に — を付けて実行します。

$ rerun -- kubectl get events -w

インストール

rerun は、Go で実装したシングルバイナリなので、macOS / Linux 環境では、下記サイトよりバイナリをダウンロードすれば利用できます。

https://github.com/shin1x1/rerun/releases

go get でもインストールできます。

$ go get -u github.com/shin1x1/rerun

さいごに

簡単な仕組みのツールですが、個人的には重宝していて、わりと便利に使ってます。最近は、下記のように Docker Desktop 自体を rerun で起動して、Docker が落ちても自動で起動するようにしています。

$ rerun /Applications/Docker.app/Contents/MacOS/Docker

サーバのデーモンを起動したりするなら、systemd なり、supervisord などを使う方が良いと思いますが、開発用端末ではわりと使えているので、同じようなユースケースがあれば試してみてください。

yae - YAML alias を展開して出力するツールを作りました

2019-05-20T14:39:31+09:00

yae という YAML の alias を anchor の内容に展開した YAML を出力するコマンドを Go で書きました。

github.com

YAML anchor/alias
yae

YAML anchor/alias

YAML では、anchor と alias を利用することで、共通のノードをまとめることができます。

下記が、anchor を alias を利用した例です。&book が anchor となっており、*book が alias となっています。これは、&book の内容が、 *book の箇所に展開されるイメージです。また、<<: を使うことで、anchor の内容の一部のキーを上書きすることもできます。

anchors:
  items:
    - &book # anchor
      name: book
      price: 100

stocks:
  - *book # alias
  - <<: *book # merge key
    price: 200 # &book の price を上書き

上の YAML を anchor / alias を使わずに書くと下記のようになります。

anchors:
  items:
  - name: book
    price: 100
stocks:
- name: book
  price: 100
- name: book
  price: 200

https://yaml.org/spec/1.2/spec.html https://yaml.org/type/merge.html

yae

YAML の alias が実際にどのように展開されるかを確認するためにこのツールを作りました。

また、長い YAML を便利な anchor / alias を使って、リファクタリングする時に、元の YAML とリファクタリング後の YAML が同じ内容になっているかを比較するのにも利用できます。

Go で実装したのですが、単に YAML を読んで、出力しているだけです。Go は、こういう小さなツールをサクッと作るのに、ほんと便利ですね。

インストール

yae は、Go で実装したシングルバイナリなので、macOS / Linux 環境では、下記サイトよりバイナリをダウンロードすれば利用できます。

https://github.com/shin1x1/yae/releases

go get でもインストールできます。

$ go get -u github.com/shin1x1/yae

利用方法

yae コマンドで alias を展開したい YAML ファイルを指定するだけです。実行すると、標準出力に展開された YAML が出力されます。なお、出力される YAML は、意味として元のもとと同じですが、インデントなどは整形されます。

$ cat src.yaml
---
anchors:
  items:
    - &book
      name: book
      price: 100

stocks:
  - *book
  - <<: *book
    price: 200

$ yae src.yaml
anchors:
  items:
  - name: book
    price: 100
stocks:
- name: book
  price: 100
- name: book
  price: 200

元の YAML との比較

上述したように、このコマンドでは、リストのインデントやキーの並びのように YAML として意味が変わらない部分は変更される場合があるので、diff を取る場合は、下記のように元の YAML も yae コマンドを通して比較した方が余計な差分が出なくて良いです。

$ diff <(yae base.yaml) <(yae refactored.yaml)

「フレームワークとの付き合い方」を発表しました / Laravel JP Conference

2019-02-16T15:30:33+09:00

Laravel JP Conference にて「フレームワークとの付き合い方」を発表しました。

発表資料

Toggeter: https://togetter.com/li/1319786

フレームワークの付き合い方について、自分なりの考えをお話しました。アップしたスライドには、発表用スライドではカット部分などを含めています。

途中で、マイクが使えなくなったりましたが、地声で届く範囲だったのでそのまま続行しました :) マイクを持たないと両手がフリーになるので、身振り手振りがやりやすくて話やすくなるというのは大きな発見でした。

セッションを聞いていいただいた方、ありがとうございました。

グラレコ

@kozzy0919 さんがグラレコでまとめて下さいました。ありがとうございます！

#laraveljpcon で「フレームワークとの付き合い方」を講演いただいた @shin1x1
さんに許可をいただいたので、内容をデジタルグラレコした画像をシェアします〜。@shin1x1 さん、ありがとうございました！ pic.twitter.com/azLj3D454p
— kozzy (@kozzy0919) February 16, 2019

Ask the speaker

セッションの後は、Ask the speaker で質疑応答を行いました。何名かの方に質問に来て頂いて、内容についてお話したのですが、じっくりとフィードバックや質問を聞いて、PC をお互いに見ながら落ち着いて話ができたのでとても良かったです。

質疑応答は、会場でみんなで共有するのが良いと思っていましたが、今終わったセッションをネタに議論ができるので面白かったです。

さいごに

Laravel というフレームワークをテーマにしたイベントということもあったのか、いつもの PHP 系イベントに参加しない方も多かったようで新鮮でした。

スタッフのみなさん、楽しいイベントをありがとうございました！

「明日から使えるアーキテクチャ独立したコアレイヤパターン」を発表しました / PHP カンファレンス仙台 2019

2019-01-29T00:00:00+09:00

仙台初開催の PHP カンファレンス仙台 2019 にて「明日から使えるアーキテクチャ独立したコアレイヤパターン」を発表しました。

発表資料

サンプルコード: https://github.com/shin1x1/phpconsen2019
Toggeter: https://togetter.com/li/1313010

独立したコアレイヤパターンについて発表しました。当初は、昨年末に東京で行われた PHP カンファレンス 2018 で発表したものと同じ内容にしようと考えていたのですが、下記のような考えももあり、資料を大幅に変更しています。

色々なフィードバックを受けて、話して、現場で適用してと繰り返す内に、このパターンにおいて本質でないものが濾過されていって、コアの部分（レイヤの名前じゃなく）が残ってきた。そのあたりを今日話したい。
— Masashi Shinbara (@shin1x1) January 25, 2019

今回は、既に実装されている API の実装にコアレイヤパターンを適用するというデモを入れました。やっぱりデモを入れた方が、具体的にイメージしやすいですし、説明もしやすいですね。やって良かったです。

PHP カンファレンスで発表したものと合わせて見ていただければ理解が進むと思うので、こちらもどうぞ。

サンプルコード: https://github.com/shin1x1/phpcon2018-independent-core-layer
Togetter: https://togetter.com/li/1299453

スーパーヒーローがいなくても使えるパターン

今回の発表で伝えたかったことの一つがこれです。レイヤ分けや抽象を利用した分離は、アーキテクチャを積極的に学んでいる人やオブジェクト指向開発に詳しい人だけが使えるというものではありません。今回発表したようなレイヤ分けの手順を踏めば、適用することが可能です。

もちろん、実際の現場では考慮すべき点は出てきますが、少なくともレイヤを分けて、インターフェイスを抽出し、アダプタを実装するというベースを作るところまでは機械的にできるでしょう。

興味を持った方は、試しに、日頃から取り組んでいるコードに対してパターンを適用してみて、その感覚を体験してみて下さい。

質疑応答

発表後の質疑応答にていくつか質問を頂きました。その中で、実際にこのパターンを適用されている方からの質問がありました！DDD + 独立したコアレイヤパターンという構成で開発されているとのことです。私が関わっていないプロジェクトでも活用されているのを聞くと嬉しいですね。どこかで機会があれば、詳しくお話聞ければ嬉しいです。

空気読まず、2つ質問してみた結果、モヤモヤしていた疑問が解決した！
今の大きめのプロジェクトは、独立したコアレイヤパターンwith DDDスタイルで書いていて見通しが非常に良くなっている。 https://t.co/dowEcJ62BJ
— 高木翔太 (@0su43) January 26, 2019

さいごに

カンファレンスでは、興味を惹かれるセッションも多く、ラフに話ができるアンカンファレンスなどもあって、楽しい時間を過ごすことができました。個人的には、カンファレンス会場と同じビルにホテルがあったおかげで、イベントの合間にも部屋に戻って荷物を置いたり、休憩できたりと快適でした :)

実行委員長の五十嵐さんが話されていた、こうしたイベントを開くことで仙台という地域を盛り上げていきたい、という想いには共感するところがあり、これをきっかけに盛り上がっていくといいなと思います。

スタッフのみなさん、楽しいイベントをありがとうございました！

Vue.js + Vuex + TypeScript ファーストインプレッション

2018-11-15T22:40:00+09:00

日頃は、サーバサイドの開発が主なのですが、その UI としてフロントエンドの開発も行うことがあります。最近話題の Vue.js を試してみたのでその感想などを。

前提
- これまで利用した構成
- Vue.js 構成
雑感
さいごに

前提

これまで利用した構成

ベースとして、これまでプロダクションで利用したことがある構成は以下です。いずれも、フォームベースの SPA で、現在も稼働しています。

AngularJS 1.x
AngularJS 1.x + TypeScript
React + Redux
React + MobX + TypeScript

Vue.js 構成

以下の構成で、ログイン、一覧表示、フォームを API サーバと通信して動作させるところまで実装してみました。

  "dependencies": {
    "axios": "^0.18.0",
    "bootstrap": "^4.1.3",
    "jquery": "^3.3.1",
    "popper.js": "^1.14.5",
    "vue": "^2.5.17",
    "vue-class-component": "^6.0.0",
    "vue-property-decorator": "^7.0.0",
    "vue-router": "^3.0.1",
    "vuex": "^3.0.1",
    "vuex-class": "^0.3.1",
    "vuex-router-sync": "^5.0.0"
  },

雑感

ちょっと試す、がすぐにできる

本家マニュアルのサンプルがそうですが、Vue.js 本体を script タグで読み込むだけで利用できます。SPA ではなくても、ページの一部に動的な要素を組み込む場合にすぐに使えるので、これだけでも道具箱に入れておくと良いですね。

https://jp.vuejs.org/v2/guide/index.html#%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB

vue-cli が楽

まず、何はともあれ開発環境の構築から。これまで経験してきた構成でもそうでしたが、ここに苦労することが多くて、開発にたどり着くまでに手間がかかり、慣れていない構成だと腰が重くなることがありました。

ただ、時代は進み、現在では、vue-cli や create-react-app などコマンドでベースは自動生成できるようになったので、かなり楽になりました。

特に vue-cli は良く出来ており、Vue.js 本体だけでなく、vue-router や Vuex、TypeScript などの組み込みも簡単にできました。初期状態では、シンプルですが、ちゃんと vue-router や Vuex を組み込んだアプリケーションも含まれるので、実装サンプルとしても参考になります。

$ vue cli sample
Vue CLI v3.1.1
? Please pick a preset: Manually select features
? Check the features needed for your project: (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◉ Babel
 ◯ TypeScript
 ◯ Progressive Web App (PWA) Support
 ◯ Router
 ◯ Vuex
 ◯ CSS Pre-processors
 ◉ Linter / Formatter
 ◯ Unit Testing
 ◯ E2E Testing

https://cli.vuejs.org/

vue ファイル

Vue コンポーネントを記述する .vue ファイルは、3 つのパートで構成されています。パートの指定にタグを使っているので、初見では戸惑ったのですが、意味が分かれば問題ありません。

React の JSX のように全てが JavaScript で表現できるというのも好きなのですが、これはこれで View / Script / Style が分離できているので分かりやすいです。デザイナさんと協業する場合は、JSX より vue ファイルの方が触ってもらいやすそうですね。

<template>
  View(HTML)
</template>

<script>
  Config, Logic(JavaScript / TypeScript)
</script>

<style>
  CSS
</style>

ちなみに、vue ファイルは、Single File Component と呼ばれるのですが、これの略称が SFC で、React 界隈で呼ばれる Stateless Functional Component の略称と同じで、はじめは戸惑いました ;)

https://jp.vuejs.org/v2/guide/single-file-components.html

template ディレクティブ

テンプレートで値のバインドや動的な操作を行いたい場合は、v-if や v-for などのディレクティブを利用します。AngularJS を使っていたので、これは特に違和感無いです。

状態によって、ビューを出し分けたい時、JSX だと、早期リターンが使えたのが楽だったのですが、Vue.js には v-else があるので、わりとすっきり書けます*1。

ただ、書き方が AngularJS に似ているので、うっかり ng-if と書いて、v-if に書き直すというのも何度もやってしまいます :)

scoped css

<style scoped> と宣言するだけで、コンポーネントに閉じた CSS を適用できます。最終的にどのような形式になるかは別にして、ただ宣言するだけで実現できるというのはホント楽です。

今回は、bootstrap を利用したので、全体のスタイルとしてはこれを利用し、差分を style タグ内で指定するという形を取りました。

vue-router / Vuex 連携

SPA を実装するとなるとルータやストア（ステート）管理が欲しくなります。Vue.js ではこうした機能は別パッケージとなっていますが、公式のパッケージとして扱われており、導入もスムーズに行えます。

vue-cli でインストールすれば、単にオプションを選択するだけなので、別パッケージということを意識する必要もなく利用できます。このあたりの連携も苦労するポイントだったりするので、簡単に導入できるのは良いですね。

React のようにそれぞれのパッケージが独立しているのは利点でもあるので、一長一短はありますが、導入が楽なのは Vue.js でした。

Vuex

Flux アーキテクチャが導入したかったので、Vuex を組み込みました。さらっとドキュメントを見ると、reducer が mutation になっているくらいで概ね同じなのかなと思っていました。

触った感触では、以下のような違いを感じました。

mutation を直接呼んで、state を変更

Redux では、コンポーネントから store を変更する際は、action を発行して、対応する reducer が変更後の store を返し、それが反映されるという流れでした。

Vuex では、コンポーネントから直接 mutation を呼んで、state を変更するようです。もちろん、action を呼んで、そこから mutation を呼ぶこともできるのですが、非同期処理などが無い場合は、mutation を呼べば ok です。

サイクルは同じ方向を回るので問題は無いですし、非同期処理などが絡まない場合は action を経由しない分、実装は楽かもしれません。

コンポーネントから直接 state を操作

コンポーネントでは、state を this.$store.state.foo のように直接参照できます*2。これは値の読み取りだけでなく、代入も出来てしまうので、やりようによっては、ただのグローバル変数となります。

このあたりは開発者やチームに自制心が求められるところで、せっかく Flux アーキテクチャのライブラリを採用しているのに、サイクルとは別にあちらこちらで state が変更されると、かえって悲惨なことにも成りかねません。

コードレビューでコンポーネントからは state を直接参照しない、少なくとも値の変更はしないなどのチェックは必要そうです。lint ツールでこういうチェックができるといいですね。

mapGetters() や mapActions() のようなヘルパー関数を使って、必要なもののみコンポーネントにマップする方法もあるので、こちらの方が行儀は良さそうです。

TypeScript

TypeScript 自体の導入は簡単です。初期設定が終わっていれば、コンポーネントでも <script lang="ts"> を宣言するだけで、その中のスクリプトは TypeScript で書くことができます。

ただ、テンプレートは TypeScript では無いので、補完や型チェックが不十分だったり、Vuex の連携でもその恩恵が薄かったりします。

完全な型チェックを求めると不満があるかもしれませんが、JavaScript よりはチェックが機能しますし、導入も簡単なので、TypeScript で書くつもりです。このあたりは、フレームワーク、ライブラリ、ツールの進化で改善していきそうですしね。

Vue.js 入門

Vue.js 触るにあたって、Vue.js入門基礎から実践アプリケーション開発までを読みました。これはいいですね。

この手のフレームワークのサンプルは、1 画面で完成するカウンターや Todo アプリが多く、一覧画面とフォーム画面で構成するようなサンプルは意外と少なかったりします。

その点、この本では、まさにこうした構成のサンプルアプリケーションを題材として扱っており、完全に自分のニーズにフィットした内容でした。タイトルに「入門」とは付いています*3が、開発現場で Vue.js を導入する際に使える内容がふんだんに盛り込まれています。

Vue.js を試すなら、まずはこの本からはじめるのがオススメです！

さいごに

そんな感じで、Vue.js を試してみた感触を書いてみました。導入の障壁が低いので、ページの一部から SPA まですぐに試せるのが良いですね。Laravel が採用しているのも分かる気がします :)

React も良いので、それはそれで継続して使っていこうとは思いますが、ツールの一つとして Vue.js も触っておいて損は無さそうです。React やっていれば、キャッチアップは楽なので、試してみるのも良いですよ。

*1:AngularJS だと ng-if が複数並ぶのがウーンという感じでした。

*2:公式ドキュメントにも記載されている方法です。

*3:書名を決めるには色々な要素があるので、著者陣の思ったとおりになるとは・・・おっと、誰か来たようだ

「PHPフレームワーク Laravel Webアプリケーション開発」を執筆しました

2018-09-13T11:30:00+09:00

PHPフレームワーク Laravel Webアプリケーション開発を共著で執筆しました。

@ex_takezawa @kurikazu @shin1x1 @omoon の四人で書いた #Laravel 本がもうすぐ出ます！5.5 LTS 対応で、機能解説だけでなく、利用例を示した実践的な内容になっています。絶賛、予約受付中なので、よろしくお願いしますー！ https://t.co/CnIK6xDhYx
— Masashi Shinbara (@shin1x1) September 10, 2018

Laravel 5.5(LTS) に対応した本です。Laravel リファレンスのようにフレームワークの機能解説はもちろん含まれているのですが、機能を紹介するというより、実際にありそうなユースケースでどのように利用するかといった視点で書かれており、開発現場で Laravel をより活用したい向けの内容になっています。目次を見ると、実践的な内容が多く含まれていることが分かるでしょう。

私は、8 章のコンソールアプリケーションと 9 章のテストを担当しました。

8 章では、EC サイトなどの購入情報を TSV で出力するコマンドや外部システムへ JSON として送信するバッチ処理を題材に解説しています。9 章では、会員ポイント加算処理を題材にユニットテスト、データベーステスト、WebAPI のテスト（フィーチャテスト）を解説しています。これらの題材となるアプリケーションでは、実装ロジックを Controller や Command に直接実装するのではなく、ユースケースクラスやサービスクラスへ分離するなど、ただフレームワークを使うのではなく、現場でどう活用するかというアイデアを盛り込んでいます。

本書が、日々の Laravel アプリケーション開発のお役に立てれば嬉しいです。

絶賛 Amazon で予約受付中ですので、よろしくお願いしますm( )m

PHPフレームワーク Laravel Webアプリケーション開発バージョン5.5 LTS対応

作者: 竹澤有貴,栗生和明,新原雅司,大村創太郎,丸山弘詩
出版社/メーカー: ソシム
発売日: 2018/09/26
メディア: 単行本
この商品を含むブログを見る

1. Laravelの概要
　1-1　Laravelとは
　1-2　環境構築
　1-3　最初のアプリケーション
2. Laravelアーキテクチャ
　2-1　ライフサイクル
　　2-1-1　Laravelアプリケーション実行の流れ
　　2-1-2　エントリポイント
　　2-1-3　HTTPカーネル
　　2-1-4　ルータ
　　2-1-5　ミドルウェア
　　2-1-6　コントローラ
　2-2　サービスコンテナ
　　2-2-1　サービスコンテナとは
　　2-2-2　バインドと解決
　　2-2-3　バインド
　　2-2-4　解決
　　2-2-5　DIとサービスコンテナ
　　2-2-6　ファサード
　2-3　サービスプロバイダ
　　2-3-1　サービスプロバイダの基本的な動作
　　2-3-2　deferプロパティによる遅延実行
　2-4　コントラクト
　　2-4-1　コントラクトの基本
　　2-4-2　コントラクトを利用した機能の差し替え
3. アプリケーションアーキテクチャ
　3-1　MVCとADR
　　3-1-1　MVC（Model View Controller）
　　3-1-2　ADR（Action Domain Responder）
　3-2　アーキテクチャへの入口
　　3-2-1　フレームワークとアーキテクチャ設計
　　3-2-2　アーキテクチャ設計のポイント
　　3-2-3　レイヤードアーキテクチャ
　　3-2-4　レイヤードアーキテクチャの一歩先の世界
4. HTTPリクエストとレスポンス
　4-1　リクエストハンドリング
　　4-1-1　リクエストの取得
　　4-1-2　Inputファサード・Requestファサード
　　4-1-3　Requestオブジェクト
　　4-1-4　フォームリクエスト
　4-2　バリデーション
　　4-2-1　バリデーションルールの指定方法
　　4-2-2　バリデーションルール
　　4-2-3　バリデーションの利用
　　4-2-4　バリデーション失敗時の処理
　　4-2-5　ルールのカスタマイズ
　4-3　レスポンス
　　4-3-1　さまざまなレスポンス
　　4-3-2　リソースクラスを組み合わせたREST APIレスポンスパターン
　4-4　ミドルウェア
　　4-4-1　ミドルウェアの基本
　　4-4-2　デフォルトで用意されているミドルウェア
　　4-4-3　独自ミドルウェアの実装
5. データベース
　5-1　マイグレーション
　　5-1-1　マイグレーション処理の流れ
　　5-1-2　マイグレーションファイルの作成
　　5-1-3　定義の記述
　　5-1-4　マイグレーションの実行とロールバック
　5-2　シーダー
　　5-2-1　シーダーの作成
　　5-2-2　シーダークラスを利用するための設定
　　5-2-3　シーディングの実行
　　5-2-4　Fakerの利用
　　5-2-5　Factoryを利用する例
　5-3　Eloquent
　　5-3-1　クラスの作成
　　5-3-2　規約とプロパティ
　　5-3-3　データ検索・データ更新の基本
　　5-3-4　データ操作の応用
　　5-3-5　関連性を持つテーブル群の値をまとめて操作する（リレーション）
　　5-3-6　実行されるSQLの確認
　5-4　クエリビルダ
　　5-4-1　クエリビルダの書式
　　5-4-2　クエリビルダの取得
　　5-4-3　処理対象や内容の特定
　　5-4-4　クエリの実行
　　5-4-5　トランザクションとテーブルロック
　　5-4-6　ベーシックなデータ操作
　5-5　リポジトリパターン
　　5-5-1　リポジトリパターンの概要
　　5-5-2　リポジトリパターンの実装
6. 認証と認可
　6-1　セッションを利用した認証
　　6-1-1　認証を支えるクラスとその機能
　　6-1-2　認証処理を理解する
　　6-1-3　データベース・セッションによる認証処理
　　6-1-4　フォーム認証への適用
　　6-1-5　認証処理のカスタマイズ
　　6-1-6　パスワードリセット
　6-2　トークン認証
　　6-2-1　api_tokenを保持するテーブルの作成
　　6-2-2　シーダーを用いたレコードの作成
　　6-2-3　独自認証プロバイダの作成
　　6-2-4　トークン認証の利用方法
　6-3　JWT認証
　　6-3-1　tymon/jwt-authのインストール
　　6-3-2　tymon/jwt-authの利用準備
　　6-3-3　tymon/jwt-authの利用方法
　　6-3-4　トークンの発行
　6-4　OAuthクライアントによる認証・認可
　　6-4-1　Socialite
　　6-4-2　GitHub OAuth認証
　　6-4-3　動作拡張
　　6-4-4　OAuthドライバの追加
　6-5　認可処理
　　6-5-1　認可処理を理解する
　　6-5-2　認可処理
　　6-5-3　Bladeテンプレートによる認可処理
7. 処理の分離
　7-1　イベント
　　7-1-1　イベントの基本
　　7-1-2　イベントの作成
　　7-1-3　イベントを利用した堅実なオブザーバーパターン
　　7-1-4　イベントのキャンセル
　　7-1-5　非同期イベントを利用する分離パターン
　7-2　キュー
　　7-2-1　キューの基本
　　7-2-2　非同期実行ドライバの準備（Queueドライバ）
　　7-2-3　キューの仕様
　　7-2-4　キューによるPDFファイル出力パターン
　　7-2-5　Supervisorによる常駐プログラムパターン
　　7-2-6　手軽な分散処理パターン
　7-3　イベントとキューによるCQRS
　　7-3-1　CQRS（コマンドクエリ責務分離）
　　7-3-2　アプリケーション仕様
　　7-3-3　アプリケーション実装の準備
　　7-3-4　口コミ登録機能の実装
　　7-3-5　口コミ投稿コントローラ実装
　　7-3-6　リスナークラスによるElasticsearch操作
　　7-3-7　Commandの実行・Queryの実装
8. コンソールアプリケーション
　8-1　Commandの基礎
　　8-1-1　クロージャによるCommandの作成
　　8-1-2　クラスによるCommandの作成
　　8-1-3　Commandへの入力
　　8-1-4　Commandからの出力
　　8-1-5　Commandの実行
　8-2　Commandの実装
　　8-2-1　サンプル実装の仕様
　　8-2-2　Commandの生成
　　8-2-3　ユースケースクラスとサービスクラスの分離
　　8-2-4　ユースケースクラスの雛形を作成する
　　8-2-5　サービスクラスの実装
　　8-2-6　ユースケースクラスの実装
　　8-2-7　Commandクラスの仕上げ
　8-3　バッチ処理の実装
　　8-3-1　バッチ処理の仕様
　　8-3-2　Commandクラスの実装
　　8-3-3　ユースケースクラスの実装
　　8-3-4　Commandクラスの仕上げ
　　8-3-5　バッチ処理のログ出力
　　8-3-6　チャットサービスへの通知（チャットワーク）
9. テスト
　9-1　ユニットテスト
　　9-1-1　テスト対象クラス
　　9-1-2　テストクラスの生成
　　9-1-3　テストメソッドの実装
　　9-1-4　データプロバイダの活用
　　9-1-5　例外のテスト
　　9-1-6　テストの前処理・後処理
　　9-1-7　テストの設定
　9-2　データベーステスト
　　9-2-1　テスト対象のテーブルとクラス
　　9-2-2　データベーステストの基礎
　　9-2-3　Eloquentクラスのテスト
　　9-2-4　サービスクラスのテスト
　　9-2-5　モックによるテスト（サービスクラス）
　9-3　WebAPIテスト
　　9-3-1　WebAPIテスト機能
　　9-3-2　テスト対象のAPI
　　9-3-3　APIテストの実装
　　9-3-4　WebAPIテストに便利な機能
10. アプリケーション運用
　10-1　エラーハンドリング
　　10-1-1　エラー表示
　　10-1-2　エラーの種別
　　10-1-3　エラーハンドリングの基本
　　10-1-4　Fluentdの活用
　　10-1-5　例外の描画テンプレート変更
　　10-1-6　エラーハンドリングパターン
　10-2　ログ活用パターン
　　10-2-1　ログの基本
　　10-2-2　ログ出力設定
　　10-2-3　権限によるログファイル分離方法
　　10-2-4　カスタムログドライバの実装
　　10-2-5　Laravel 5.6でのElasticsearchログドライバ
　　10-2-6　Laravel 5.5でのElasticsearchログドライバ
11. テスト駆動開発の実践
　11-1　テスト駆動開発とは
　　11-1-1　コツはできるだけ小さく
　　11-1-2　サンプルアプリケーション仕様
　　11-1-3　データベース仕様
　　11-1-4　APIエンドポイント
　11-2　APIエンドポイントの作成
　　11-2-1　アプリケーションの作成・事前準備
　　11-2-2　最初のテスト
　　11-2-3　テストメソッドに何をどのように書くか
　　11-2-4　最低限の実装
　　11-2-5　2つ目以降のテスト
　　11-2-6　1つのテストメソッドに検証は1つの原則
　　11-2-7　テストコードの確認
　11-3　テストに備えるデータベース設定
　　11-3-1　データベース設定
　　11-3-2　マイグレーション・モデル・ファクトリ
　　11-3-3　初期データ投入用シーダーの準備
　11-4　データベーステスト
　　11-4-1　テスト用トレイトの利用・初期データの投入
　　11-4-2　データベースが絡むテスト
　　11-4-3　仮実装で素早くテストを成功させる
　　11-4-4　最初のリファクタリング
　　11-4-5　返却値の内容を検証
　　11-4-6　成功が分かっているテストの追加
　　11-4-7　データ追加の検証
　　11-4-8　既存テストの修正
　　11-4-9　バリデーションテスト
　11-5　リファクタリングユースケース
　　11-5-1　そろそろコントローラを使う
　　11-5-2　フレームワークの標準に寄せていくリファクタリング①
　　11-5-3　正確なテストが書けない時の対処法
　　11-5-4　フレームワークの標準に寄せていくリファクタリング②
　　11-5-5　サービスクラスへの分離

ab ライクに SQS にエンキューするツール en9sqs

2018-06-29T13:17:57+09:00

SQS から AWS Lambda をトリガーできるようになりましたね！ワーカーを AWS Lambda で動かせるので、これは嬉しいリリースです。

aws.amazon.com

en9sqs

こういった機能を試すには、SQS にメッセージをエンキューする必要があるわけで、パフォーマンスを見たい時は大量にメッセージを投下したい場合もあったりします。

そんな時に便利なのが、en9sqs というツールです。 golang で書いており、並列にメッセージをエンキューできます。

github.com

インストール

インストールするには、go get を使うか、64bit macOS 用ならバイナリが releases にあるので、これをダウンロードするのが良いでしょう。

$ go get -u github.com/shin1x1/en9sqs

Releases · shin1x1/en9sqs · GitHub

実行例

下記が実行例です。ab（Apache Bench）と同様に、-c が並列度で、-n がメッセージ総数を指定します。その後に、キューの URL、そして送信するメッセージを指定します。

# 1,000 件のメッセージを 10 並列で送信
$ en9sqs -c 10 -n 1000 https://sqs.ap-northeast-1.amazonaws.com/xxxxxx/hogehoge "Hello"
2018/06/29 13:15:22 message 100 done(worker:5)
2018/06/29 13:15:22 message 200 done(worker:3)
2018/06/29 13:15:22 message 300 done(worker:7)
2018/06/29 13:15:23 message 400 done(worker:10)
2018/06/29 13:15:23 message 500 done(worker:3)
2018/06/29 13:15:23 message 600 done(worker:5)
2018/06/29 13:15:24 message 700 done(worker:4)
2018/06/29 13:15:24 message 800 done(worker:8)
2018/06/29 13:15:24 message 900 done(worker:1)
2018/06/29 13:15:25 message 1000 done(worker:10)
2018/06/29 13:15:25 Done(1000 messages)

ツールとして、並列数やメッセージ数に制限はかけていないですが、あまりに並列数を上げすぎると SQS がエラーを返すようになるので注意して下さい。

さいごに

golang だとこういった並列で何かをするツールをサクッと書けるので良いですね！機能としては、まだ追加したいもの（メッセージのテンプレート化、sleep 機能など）もあるので、ぼちぼち追加していきます。もちろん、PR も歓迎ですー。

独立したコアレイヤパターン

2018-05-11T00:55:05+09:00

モチベーション
全体
サンプルアプリケーション
コアレイヤ
サービスレイヤ
口座間送金ユースケース
コアレイヤ対象範囲
- DDD スタイル
- 手続き型スタイル
実装アイデア
さいごに
参考

独立したコアレイヤは、アプリケーション実装パターンである。以下のような特徴を持つ。

アプリケーションを、何を実現するのか（What）と、どのように実現するのか（How）に分ける。
What は、コアレイヤに実装する。ユースケースやドメインロジックを実装する。フレームワークやライブラリには依存しない。UI やデータベースからは独立している。
How は、サービスレイヤ（仮）に実装する。フレームワークやライブラリを活用して、ユースケースが要求する技術詳細を実装する。
コアレイヤが必要な技術詳細はポート（インタフェース）で定義し、これに依存する。サービスレイヤでは、それに対するアダプタを実装する。

ここでは、Web アプリケーションを念頭においているが、内容は Web アプリケーションに特化するものではなく、他種のアプリケーションでも適用可能と考える。

モチベーション

技術詳細からの独立

コアレイヤでは、ユースケースやドメインを記述するが、UI、フレームワークやサードパーティライブラリ、外部ミドルウェア通信等の詳細技術とは独立しているので、処理の流れやドメインロジックといった何を実現するのかを平易に記述していくだけで良い。こうしたコードは、後に他の開発者がコードを見た時にもアプリケーションが実現したいことが把握しやすい。

フレームワーク、サードパーティライブラリからの独立

コアレイヤは、フレームワークやサードパーティライブラリには依存しない。こうした機能は、ポート経由で間接的に利用する。あくまでコアレイヤは、ポートに依存しているだけでその詳細には関与しない。こうしておくことで、フレームワークやライブラリのバージョンアップや入れ替えが発生しても、その影響はサービスレイヤで実装するアダプタに留まり、コアレイヤには及ばない。

サービスレイヤからの独立

コアレイヤは、サービスレイヤにも依存しないので、単体のアプリケーションとして利用することも可能である。つまり、テストランナーを使えば、単体でテストを実行できる。また、異なるサービスレイヤ、例えば Web アプリケーションとバッチアプリケーションがあっても、同じコアレイヤを使うことができる。

コアレイヤからの独立

サービスレイヤについても、コアレイヤから独立していることで、要求される技術に特化した処理を実装すれば良くなる。HTTP リクエストのハンドリング、レスポンス生成、データベースアクセス、メール送信といったものだ。こうしたものは、汎用フレームワークやライブラリで提供されているので、それらをアダプタとして、コアレイヤに提供すれば良い。

シンプルなルール

本パターンで定めているのは、レイヤをコアレイヤとサービスレイヤの 2 つに分ける、コアレイヤは外部の技術詳細に依存せずに自身で定義したポートに依存する、だけである。

このシンプルなルールにより、小さなアプリケーションにも適用しやすいものとなっている。

全体

下記に独立したコアレイヤパターンのイメージ図を示す。

この図を見れば、ヘキサゴナルアーキテクチャやオニオンアーキテクチャ、クリーンアーキテクチャを想起するだろう。本パターンは、ヘキサゴナルアーキテクチャ（ Ports and Adapters パターン）の一種である。コアレイヤを中心におき、外部にある実装はインタフェース経由で利用する。

前述したアーキテクチャと異なるのは、レイヤ構造を 2 つにしている点とポートの種類や役割を限定していないことである。例えば、ヘキサゴナルアーキテクチャでは、ポートをプライマリとセカンダリに区分している。細かな違いではあるが、定義を明確にするために新たな名称を付けた。

サンプルアプリケーション

本エントリで提示するコードは、下記リポジトリにある。Docker 開発環境を構築できるので、テストなど動かしてみると良いだろう。

github.com

コアレイヤ

コアレイヤは、ユースケースとユースケースが利用するサービスのポート（インタフェース）を実装する。ユースケースは、想定される処理を順に記述していく。データベースアクセスなど技術詳細を利用したい場合、必要な API をインタフェースとして実装して、それに依存しておく。ユースケース内では、このインタフェースを利用して値の取得や保存などの処理を行う。

アプリケーションドメインに関する実装、エンティティや ValueObject、ドメインサービスなど、もコアレイヤに含める。ただ、これは必須ではなく、シンプルなユースであればこうしたドメインモデルを使わずにユースケースを実装する場合もある。

このレイヤに技術詳細は含まないので、Web アプリケーションフレームワークやサードパーティライブラリなどには依存しない。ただし、データやアルゴリズムなどを提供するライブラリについては依存する場合がある。例えば、PHP であれば、日付時間ライブラリである Carbon や Chronos 、データ構造ライブラリの php-ds*1 などの依存は考えられる。

以下に一つの例を示す。ここでは、銀行口座の情報を取得するユースケースを実装している。

なお、本エントリ全体で例示するソースコードは、シンプルな銀行口座アプリケーションのものである。また、AccountNumber や Account などはドメインモデルとして、このレイヤに含まれているとする。

<?php
declare(strict_types=1);

namespace Acme\Account\UseCase\GetAccount;

use Acme\Account\Domain\Exceptions\NotFoundException;
use Acme\Account\Domain\Models\Account;
use Acme\Account\Domain\Models\AccountNumber;

final class GetAccount
{
    private $query;

    public function __construct(GetAccountQueryPort $query)
    {
        $this->query = $query;
    }

    public function execute(AccountNumber $accountNumber): Account
    {
        return $this->query->findAccount($accountNumber);
    }
}

interface GetAccountQueryPort
{
    public function findAccount(AccountNumber $accountNumber): Account;
}

GetAccount クラスがユースケース、GetAccountQueryPort インタフェースがこのユースケースが利用するポートである。ユースケースでは、コンストラクタにポートを引数で受け取る。execute メソッドにユースケースを実装する。このメソッドでは、単に GetAccountQueryPort インタフェースの findAccount メソッドを実行してその戻り値を返すだけである。

execute メソッドを見れば、このユースケースが何をするかは一目瞭然である。たが、実際に口座情報がどこにあり、それをどのように行うかはコアレイヤは知らない。

ポートには、ユースケースごとに定義する。読み取り処理を担う Query ポート、データ保存やメール送信など副作用を伴う処理を担う Command ポート、アプリケーション全体で横断的に利用する Transaction ポートなど考えられる。ただ、これは本パターンで規定しておらず、あくまで一例である。

ユースケースはフレームワークやサードパーティライブラリには依存せず、データベースなどにも直接接続しないので、テスト用データベースのセットアップなどなくても簡単にテストが書ける。以下が GetAccount ユースケースのテストである。

<?php
declare(strict_types=1);

namespace Acme\Test\Account\UseCase;

use Acme\Account\Domain\Exceptions\NotFoundException;
use Acme\Account\Domain\Models\Account;
use Acme\Account\Domain\Models\AccountNumber;
use Acme\Account\UseCase\GetAccount\GetAccount;
use Acme\Account\UseCase\GetAccount\GetAccountQueryPort;
use PHPUnit\Framework\TestCase;

final class GetAccountTest extends TestCase
{
    /**
     * @test
     * @throws NotFoundException
     */
    public function execute()
    {
        $sut = new GetAccount(
            new class implements GetAccountQueryPort
            {
                public function findAccount(AccountNumber $accountNumber): Account
                {
                    return Account::ofByArray([
                        'account_number' => $accountNumber,
                        'email' => 'a@example.com',
                        'balance' => 1000,
                    ]);
                }
            }
        );

        $accountNumber = 'A0001';
        $actual = $sut->execute(AccountNumber::of($accountNumber));

        $this->assertSame($accountNumber, $actual->accountNumber()->asString());
        $this->assertSame(1000, $actual->balance()->asInt());
    }

    /**
     * @test
     * @expectedException \Acme\Account\Domain\Exceptions\NotFoundException
     */
    public function error_account_not_found()
    {
        $sut = new GetAccount(
            new class implements GetAccountQueryPort
            {
                public function findAccount(AccountNumber $accountNumber): Account
                {
                    throw new NotFoundException();
                }
            }
        );

        $sut->execute(AccountNumber::of('Z9999'));
    }
}

GetAccountQueryPort をインジェクトするだけでユースケースは実行できるので、無名クラスでこのインタフェースを実装して与えている。GetAccountTest クラスの execute メソッドでは正常ケースとして、Account インスタンスを返している。一方、error_account_not_found メソッドでは、口座情報が見つからないケースとして例外を送出している。このようにユースケースではインタフェースに依存しているだけなので、インジェクトするクラスの実装をいかようにも変えることができる。

このユースケースは、あまりにシンプルでイメージが沸かないということであれば、後述する口座間送金ユースケースの例を見ると良い。

サービスレイヤ

サービスレイヤは、UI やデータベースなどアプリケーション外部との連携を実装する。

このレイヤでは、2つの責務を担う。1 つ目は、UI からのアクションを契機にユースケースを実行することである。コアレイヤから提供されるユースケースクラスを実行することになる。2 つ目は、実行するユースケースが依存しているポートに対するアダプタを実装することだ。インタフェースを満たせば、その実装の詳細は自由である。

先の GetAccount ユースケースに対する本レイヤの実装を見ていこう。ここでは、Laravel 5.6 を利用しているものとする。

まず、GetAccount ユースケースが要求している GetAccountQueryPort に対するアダプタ実装が以下となる。

<?php
declare(strict_types=1);

namespace App\Action\GetAccount;

use Acme\Account\Domain\Exceptions\NotFoundException;
use Acme\Account\Domain\Models\Account;
use Acme\Account\Domain\Models\AccountNumber;
use Acme\Account\UseCase\GetAccount\GetAccountQueryPort;
use App\Eloquents\EloquentAccount;

final class GetAccountAdapter implements GetAccountQueryPort
{
    private $account;

    public function __construct(EloquentAccount $account)
    {
        $this->account = $account;
    }

    public function findAccount(AccountNumber $accountNumber): Account
    {
        $account = $this->account->findByAccountNumber($accountNumber);
        if (is_null($account)) {
            throw new NotFoundException(sprintf('account_number %s not found', $accountNumber->__toString()));
        }

        return $account->toModel();
    }
}

GetAccountAdapter クラスでは、GetAccountQueryPort を実装している。内部では、Eloquent を利用して、データベースから口座情報を取得し、Account インスタンスとして返している。ここでは、コンストラクタで EloquentAccount をインジェクトしているが、ファサードを使っても問題無い。サービスレイヤでは、フレームワークの機能を利用して、より開発しやすい方法で実装すれば良い。

Laravel にはサービスコンテナという DI コンテナがあるので、GetAccount クラス生成時にこのアダプタを与えるように定義しておく。ここでは、CoreServiceProvider を追加して、その中で DI コンテナに定義を追加している。

<?php
declare(strict_types=1);

namespace App\Providers;

use Acme\Account\UseCase\GetAccount\GetAccount;
use App\Action\GetAccount\GetAccountAdapter;

final class CoreServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        //
    }

    public function register(): void
    {
        $this->app->bind(GetAccount::class, function () {
            $adapter = app(GetAccountAdapter::class);

            return new GetAccount($adapter);
        });
    }
}

Laravel のルーティングからユースケースを実行する GetAccountAction は以下になる。

<?php
declare(strict_types=1);

namespace App\Action\GetAccount;

use Acme\Account\Domain\Models\AccountNumber;
use Acme\Account\UseCase\GetAccount\GetAccount;
use Illuminate\Http\Request;

final class GetAccountAction
{
    private $useCase;

    public function __construct(GetAccount $useCase)
    {
        $this->useCase = $useCase;
    }

    public function __invoke(Request $request, string $accountNumber)
    {
        $account = $this->useCase->execute(AccountNumber::of($accountNumber));

        return response()->json([
            'account_number' => $account->accountNumber()->asString(),
            'balance' => $account->balance()->asInt(),
        ]);
    }
}

コンストラクタで、先程 CoreServiceProvider でサービスコンテナに登録した GetAccount インスタンスが与えられる。ルーティングからは、__invoke メソッドが実行される。この中でパラメータのバリデーションなどを行って、ユースーケースを実行する。HTTP に関することは、このクラスで処理して、ユースーケースには渡さないようにする。ユースーケースからは、Account インスタンスが返されるので、これを JSON で出力している。

このように、アプリケーション外部やフレームワークなどに関する処理は全てこのレイヤで行う。

口座間送金ユースケース

より実際のアプリケーションに近いかたちとして、口座間の送金処理ユースケースの実装例を見る。

処理の流れ

送金元口座番号、送金先口座番号、送金金額を指定する。
送金元口座番号から送金元口座情報を取得する。
送金先口座番号から送金先口座情報を取得する。
送金元口座から送金金額を出金する。
送金先口座に送金金額を入金する。
送金元口座の取引ログに出金を記録する。
送金先口座の取引ログに入金を記録する。
送金元口座残高を保存する。
送金先口座残高を保存する。

コアレイヤ

ユースケース TransferMoney クラスは以下のようになる。

まず、3 つのポートに依存している。TransferMoneyQueryPort はデータ取得のような読み取り処理を担うポート、TransferMoneyCommandPort はデータ保存やメール送信のような副作用を伴う処理を担うポートTransactionPort は、データベーストランザクションを担う汎用ポートである。

execte メソッドでは、送信元口座番号、送信先口座番号、送金金額、そして取引ログを記録するために処理日時を引数に取る。これは、サービスレイヤから与えられる。このメソッドでは、Query ポートで口座情報取得、ドメインルール検証、ドメインロジック（送金）、Command ポートで結果の保存、通知といった処理を行っている。一連の処理は、Transaction ポートでトランザクション内で実行するようにしている。

<?php
// (snip)
final class TransferMoney
{
    private $query;
    private $command;
    private $transaction;

    public function __construct(
        TransferMoneyQueryPort $query,
        TransferMoneyCommandPort $command,
        TransactionPort $transaction
    ) {
        $this->query = $query;
        $this->command = $command;
        $this->transaction = $transaction;
    }

    public function execute(
        AccountNumber $sourceNumber,
        AccountNumber $destinationNumber,
        Money $amount
    ): Balance {
        return $this->transaction->transaction(function () use ($sourceNumber, $destinationNumber, $amount) {
            [$source, $destination] = $this->query($sourceNumber, $destinationNumber);

            if ($source->accountNumber()->equals($destination->accountNumber())) {
                throw new DomainRuleException('source can not transfer to same account');
            }

            if ($source->balance()->lessThan($amount)) {
                $message = sprintf('source account does not have enough balance for transfer %s', $amount->asInt());
                throw new DomainRuleException($message);
            }

            $source->withdraw($amount);
            $destination->deposit($amount);

            $this->store($source, $destination, $amount, $now);

            $this->command->notify($source);

            return $this->query->findAccount($sourceNumber)->balance();
        });
    }
}

query メソッドでは、Query ポートを使って、口座番号から送金元、送信先口座情報を取得している。このユースケースでは後ほど、残高を更新するためにレコードロックを獲得している。この時、デッドロックを防ぐために口座番号の若い方からロックをかけるようにしている。

<?php

    private function query(AccountNumber $sourceNumber, AccountNumber $destinationNumber): array
    {
        if ($sourceNumber->lessThan($destinationNumber)) {
            $source = $this->query->findAndLockAccount($sourceNumber);
            $destination = $this->query->findAndLockAccount($destinationNumber);
        } else {
            $destination = $this->query->findAndLockAccount($destinationNumber);
            $source = $this->query->findAndLockAccount($sourceNumber);
        }
        return [$source, $destination];
    }

store メソッドでは、入金後の口座残高を保存している。また、送金処理に関する取引ログも合わせて記録している。

<?php

    private function store(Account $source, Account $destination, Money $amount, TransactionTime $now): void
    {
        $this->command->storeBalance($source->accountNumber(), $source->balance());
        $this->command->storeBalance($destination->accountNumber(), $destination->balance());
        $this->command->addTransaction(new Transaction(
            $source->accountNumber(),
            TransactionType::WITHDRAW(),
            $now,
            $amount,
            'transferred to ' . $destination->accountNumber()->asString()
        ));
        $this->command->addTransaction(new Transaction(
            $destination->accountNumber(),
            TransactionType::DEPOSIT(),
            $now,
            $amount,
            'transferred from ' . $source->accountNumber()->asString()
        ));
    }

この実装を見て分かるようにコアレイヤでは、トランザクションやレコードロックの順序などいわゆるドメインレイヤでは扱わないコードについても対象となり得る。どこまでをコアレイヤにすべきかということは本パターンでは特に定めない。

サービスレイヤ

サービスレイヤでは、ユースケースの実行と定義されたポートに対するアダプタを実装していく。

GetAccount と同様にルーティングに設定されたアクションでは下記のようにユースケースを実行している。

<?php

    public function __invoke(TransferMoneyRequest $request, string $accountNumber)
    {
        $validated = $request->validated();
        $balance = $this->useCase->execute(
            AccountNumber::of($accountNumber),
            AccountNumber::of($validated['destination_number']),
            Money::of((int)$validated['money']),
            TransactionTime::now()
        );

        return response()->json([
            'balance' => $balance->asInt(),
        ]);
    }

ポートに対するアダプタは下記のようになる。 https://github.com/shin1x1/independent-core-layer-laravel/blob/master/app/Action/TransferMoney/TransferMoneyAdapter.php

ここでは、Query ポートと Command ポートを同じアダプタクラスで実装している。ユースケースに対するポート実装が小さいものなら、こうした実装方法も考えられる。ポートにマッチするアダプタが提供されれば良いので、どのようにアダプタを実装するかは、本パターンでは定めない。

<?php

final class TransferMoneyAdapter implements
    TransferMoneyQueryPort,
    TransferMoneyCommandPort

コアレイヤ対象範囲

本パターンを実装する上で悩むところは、コアレイヤにどこまでを含めるかという点であろう。コアレイヤに技術詳細を含めないことは当然なのだが、どこまで抽象化するかは実装者に委ねられる。それを考えるヒントとして、TransferMoney の異なる実装を 2 つ提示する。

DDD スタイル

DDD パターンを活用して、よりドメインレイヤに近いかたちで実装したのが以下の例だ。ここでは、TransferMoneyAggregate という集約を利用して、Query や Command は、この集約単位で行っている。また、ドメインルール検証も TransferMoneySpec で実装している。

execute メソッドを見るとかなりシンプルな実装となっていること分かる。ただ、上記であったレコードロックの順番に関する実装は、サービスレイヤに任せるようになっているので、コアレイヤをやや小さくしたパターンともいえる。

<?php

(snip)

final class DDDStyleTransferMoney
{
    private $query;
    private $command;
    private $transaction;

    public function __construct(
        DDDStyleTransferMoneyQuery $query,
        DDDStyleTransferMoneyCommandPort $command,
        TransactionPort $transaction
    ) {
        $this->query = $query;
        $this->command = $command;
        $this->transaction = $transaction;
    }

    public function execute(
        AccountNumber $sourceNumber,
        AccountNumber $destinationNumber,
        Money $amount,
        TransactionTime $now
    ): Balance {
        return $this->transaction->transaction(function () use ($sourceNumber, $destinationNumber, $amount, $now) {
            $aggregate = $this->query->find($sourceNumber, $destinationNumber);

            if (!(new TransferMoneySpec())->isSatisfiedBy($aggregate, $amount)) {
                throw new DomainRuleException('TransferMoneySpec is not satisfied.');
            }

            $aggregate->transfer($amount, $now);

            $this->command->store($aggregate);
            $this->command->notify($aggregate->source());

            return $this->query->findAccount($sourceNumber)->balance();
        });
    }
}

interface DDDStyleTransferMoneyQuery
{
    public function find(AccountNumber $sourceNumber, AccountNumber $destinationNumber): TransferMoneyAggregate;

    public function findAccount(AccountNumber $accountNumber): Account;
}

interface DDDStyleTransferMoneyCommandPort
{
    public function store(TransferMoneyAggregate $aggregate): void;

    public function notify(Account $account): void;
}

手続き型スタイル

次は、手続き型によるユースケースの実装を見る。ここでは、ドメインモデルは一切利用せずに string や int、array といったプリミティブな型のみで実装している。ポートでの API 定義もプリミティブな型のみ利用しているので、アダプタも array を返すような実装となる。本パターンでは、このような手続き型スタイルで実装することも可能である。

<?php

(snip)

final class ProcedureStyleTransferMoney
{
    const TRANSACTION_TYPE_WITHDRAW = 'WITHDRAW';
    const TRNSACTION_TYPE_DEPOSIT = 'DEPOSIT';

    private $query;
    private $command;
    private $transaction;

    public function __construct(
        ProcedureStyleTransferMoneyQueryPort $query,
        ProcedureStyleTransferMoneyCommandPort $command,
        TransactionPort $transaction
    ) {
        $this->query = $query;
        $this->command = $command;
        $this->transaction = $transaction;
    }

    public function execute(
        string $sourceNumber,
        string $destinationNumber,
        int $amount,
        Chronos $now
    ): int {
        return $this->transaction->transaction(function () use ($sourceNumber, $destinationNumber, $amount, $now) {
            [$source, $destination] = $this->query($sourceNumber, $destinationNumber);

            if ($sourceNumber === $destinationNumber) {
                throw new DomainRuleException('source can not transfer to same account');
            }

            if ($source['balance'] < $amount) {
                $message = sprintf('source account does not have enough balance for transfer %s', $amount);
                throw new DomainRuleException($message);
            }

            $source['balance'] -= $amount;
            $destination['balance'] += $amount;

            $this->store($source, $destination, $amount, $now);

            $this->command->notify($source);

            return $this->query->findAccount($sourceNumber)['balance'];
        });
    }

    private function query(string $sourceNumber, string $destinationNumber): array
    {
        if ($sourceNumber < $destinationNumber) {
            $source = $this->query->findAndLockAccount($sourceNumber);
            $destination = $this->query->findAndLockAccount($destinationNumber);
        } else {
            $destination = $this->query->findAndLockAccount($destinationNumber);
            $source = $this->query->findAndLockAccount($sourceNumber);
        }

        return [$source, $destination];
    }

    private function store(array $source, array $destination, int $amount, Chronos $now): void
    {
        $this->command->storeBalance($source['account_number'], $source['balance']);
        $this->command->storeBalance($destination['account_number'], $destination['balance']);

        $this->command->addTransaction([
            'account_number' => $source['account_number'],
            'transaction_type' => self::TRANSACTION_TYPE_WITHDRAW,
            'transaction_time' => $now,
            'amount' => $amount,
            'comment' => 'transferred to ' . $destination['account_number'],
        ]);
        $this->command->addTransaction([
            'account_number' => $destination['account_number'],
            'transaction_type' => self::TRANSACTION_TYPE_DEPOSIT,
            'transaction_time' => $now,
            'amount' => $amount,
            'comment' => 'transferred from ' . $source['account_number'],
        ]);
    }
}

interface ProcedureStyleTransferMoneyQueryPort
{
    public function findAndLockAccount(string $accountNumber): array;

    public function findAccount(string $accountNumber): array;
}

interface ProcedureStyleTransferMoneyCommandPort
{
    public function storeBalance(string $accountNumber, int $balance): void;

    public function addTransaction(array $transaction): void;

    public function notify(array $account): void;
}

実装アイデア

レイヤでパッケージを分ける

コアレイヤは、それ単独で成り立つものなので、パッケージを分けてしまう方法も考えられる。ここでいうパッケージとは、ビルドや配布ができる単位で、PHP であれば composer パッケージ、Java なら jar ファイルといったものだ。このようにパッケージを分けることで、コアレイヤが依存する外部パッケージを必要最低限なものに制限でき、ビルドサイクルも分離できる。小さなアプリケーションでは考慮する必要は無いが、多くのユースケースを抱える場合やリリースサイクルを分ける場合は一考の余地があるだろう。

コアレイヤの範囲

前述したとおり、コアレイヤにどこまで含めるのかが本パターンの肝となる。最も範囲を広げるなら、技術詳細を使う一歩手前、分かりやすいところではフレームワークやライブラリの機能を利用する直前までとなる。反対にコアレイヤを狭めていき、ドメインレイヤのみなどにもできるが、そうなるとサービスレイヤにアプリケーションロジックが多数入り込むことになるので、分離という意味では効果が薄くなるかもしれない。

ポートの種類

本エントリでは、ポートをユースケース毎に定義し、その種類を Query、Command、Transaction としている。これには他のアプローチも考えられる。例えば、Command であれば、Account の保存と Transaction の保存、通知を別のポートとして定義することも考えられる。また、ユースケース毎ではなく、複数のユースケースで共通に利用できるように、利用用途でポートを定義する方法もあるだろう。

DDD スタイルへの一歩目

すでに見てきたように本パターンは、様々なスタイルでの開発に適用できる。開発初期は、フレームワークの流儀で実装しておく。次に、本パターンを活用してコアレイヤを独立させる。ここまで来れば、コアレイヤはフレームワークから独立しているので、技術詳細から独立したドメインレイヤを作るのは難しくない。このように、ドメインレイヤを作る一歩目として利用する方法も考えられる。

さいごに

Webアプリケーション開発において、オープンソースフレームワークやライブラリの活用は当然のこととなっている。ただ、特にフレームワークに関しては、アプリケーションの基盤として包括的に利用するので密結合になる傾向がある。初期開発においては、フレームワークに密結合で開発することは、動くものを速く作ることができるという悪くない選択だ。しかし、こうしたアプリケーションを運用していくと、フレームワークのバージョンアップの度にアプリケーション全体に手を入れることになり、開発の俊敏性が失われたり、変更コストが大きくなることがある。

あくまで、アプリケーションが主であり、フレームワークはそれを実現する一手段、ツールに過ぎない。フレームワークを利用しつつも、いかにアプリケーションコアと分離するか、影響を受けないようにするかという観点から、このパターンを考案した。

開発当初から想像するより、意外とアプリケーションの寿命は長い。初期開発時時に、どこまで先を見越してレイヤ分離を行うかはケースによるだろうが、本パターンであれば、それほど大きな工数をかけずに実現できるのではと見ている。長く運用され、価値を出し続けているアプリケーションに携わっている人のヒントになれば嬉しい。

参考

*1:http://php.net/manual/ja/book.ds.php

懇親会ではなく本編で交流できた PHPerKaigi 2018

2018-03-22T21:49:02+09:00

phperkaigi.jp

PHPerKaigi 2018 に参加してきました。

「PHP の現場」公開収録

主催の長谷川さんからお誘いを頂き、 @goodoo さんをゲストにお招きして、「PHP の現場」の公開収録をやってきました。

「初の公開収録」と言いたいところなのですが、1 回目が勉強会で話している模様の録音だったので、それを入れると 2 回目ですね。公開収録と銘打って収録したのが初です。

Twitter で公開収録を呼びかけたところ、立ち見の方が出るほど多くの方に集まっていただきました！ありがとうございましたm(_ _)m

せっかく集まって頂いたのですが、私と @goodoo さんとで向き合って話すスタイルだったのと賑やかな会場だったこともあり、音声が聞きづらい状況になってしまいました。。。

正直、音源に周りの音がのることは予想していたのですが、収録現場で話している声が聞き取りづらくなるのは考えていませんでした。会場が予想よりもかなり盛り上がっていたということは、イベントとして大成功なので、これは全く問題ありません。

公開収録に望む環境作りの話なので、今回のことは貴重な経験として、次回があれば生かしていきたいです。

当日の収録分はすでに公開していますので、こちらでお楽しみ下さい。

php-genba.shin1x1.com

togetter.com

懇親会の盛り上がりを本編で

イベントに目を向けると、Track A は素晴らしいセッションが目白押しでした。そして、Track B の盛り上がりが印象的でした。

上記でも少し触れましたが、Track B には丸テーブルとそれを囲む椅子、ホワイトボードが複数用意されており、テーマを決めて、ディスカッションができるようになっていました。

それ以外にもテーブルや椅子は用意されており、自由に話したり、ハックしたりできるようになっています。また、コーヒーやドーナッツといった軽食も用意されていて、Track A を聞いて一息付きたい時に自然と足を運ぶようになっていたのも良かったです。

トークセッションを聞き続けるのは意外に疲れるので補給できるスペースはありがたいです。以前参加した Microsoft の Build でも飲食が充実していて、廊下には常にドリンクや軽食があったので、セッションが終わるごとに何か食べていた気がします ;)

この盛り上がりは、自分が運営するイベントで課題として考えていた「懇親会が本番」問題の一つの解を見た気がします。

www.1x1.jp

やはり、色々な人と技術の話をして楽しむというのは、同じ場所に人が集まるカンファレンスならではのものです。もちろん、これは懇親会でできることなのですが、どうにかそれを本編でできないかというのが頭の中にありました。また、アルコールがそれほど得意ではない人間からすると、飲まずに交流できる場があるというのもいいなとも思います。飲みの席は好きなのですが、盛り上がりすぎると腰を据えてじっくりと話すというより、ノリ優先で盛り上がる方向に行くので、そうでは無い場も欲しかったりします。（ノリ優先で盛り上がるのも好きです！）

ただ、交流となると、知り合いがいれば良いですが、見ず知らずの人と話すのは難しいものです。それを解決する方法として「Ask The Speaker」や相談会といった企画が上手く機能していたように見えました。私も「Laravel 相談会」に少し参加したのですが、参加している方々から色々な質問が出てきて、それについてみんなで話すというのが自然に行われていました。話題が提供されているというのはすごく良くて、お互いを知らない者同士でも話しやすいです。これは素晴らしい取り組みでした。

「アンカンファレンス」じゃなくて「相談会」と名付けたもの、何をする場なのかが分かりやすくて、うまいなあと。

これだけ盛り上がった Track B なので、来年はもっと広い会場でゆったりできるようになると嬉しいです！

次のイベントへの橋渡し

長谷川さんの最後の挨拶で印象的だったのが、福岡や関西といった他の地方のカンファレンスへの誘導を積極的に行っていたことでした。

実際、TL などを見ていると多くの人が、福岡や関西に行きたい！と書いていて、トークにも応募したようです。福岡では、前年よりトーク応募数が増えたようですけど、これは PHPerKaigi での煽動（？）が一部効いているのではないでしょうか。

こうして主催者が、次のイベントへの橋渡しをするというのも、これまであまり無かったので、全てのイベントが一つのコミュニティにあるというのがあらためて感じられて良かったです。

さいごに

公開収録や Track A のセッション、Track B の交流などなど盛りだくさんで楽しいイベントでした。

素晴らしいイベントをありがとうございました。来年も楽しみにしています！

PHPerKaigi の現場

というような話を PHP の現場で収録します。

ゲストは、もちろん @tomzoh さんと @cakephper さんです。お楽しみに :)

【追記】公開しました。

php-genba.shin1x1.com

PhpStorm + Docker for Mac（docker-compose）での PHPUnit と Remote Debug の設定

2017-10-27T07:00:00+09:00

PhpStorm から Docker for Mac の Docker コンテナ内で PhpUnit のテスト実行や Remote Debug を行うための設定です。

下記バージョンにて構築を行いました。

PhpStorm 2017.2.4
Docker for Mac 17.09.0-ce-mac35
PHP 7.1（ php:7.1-apache ベース）
Xdebug 2.5

サンプルプロジェクトの取得

サンプルプロジェクトを用意したので、このプロジェクトをベースに設定を行います。このプロジェクトには、初期状態の Laravel アプリケーション（5.5）が含まれています。

github.com

git で clone して、make を実行すると composer install と docker-compose up が実行されます。ブラウザで、 http://localhost:8000/ にアクセスすると、Laravel の初期画面が表示されます。

$ git clone https://github.com/shin1x1/phpstorm-with-docker-for-mac-sample
$ cd phpstorm-with-docker-for-mac-sample

$ make
もしくは
$ docker-compose run composer install
$ docker-compose up -d

docker-compose.yml は下記のようになっています。

php-cli は PHPUnit を実行する、web は Web アプリケーションを実行するサービスです。現状、web サービスを起動中に PhpStorm から PHPUnit を実行すると、先に起動していた web コンテナが落ちるので、それを回避するためです。

どちらも image や volumes などの設定は同じです。web はポートマッピングを指定しています。

version: '3'
services:
  php-cli:
    build: ./docker/web
    volumes:
      - ./:/var/www/html
      - ./docker/web/php.ini:/usr/local/etc/php/php.ini
    working_dir: /var/www/html
  web:
    build: ./docker/web
    volumes:
      - ./:/var/www/html
      - ./docker/web/php.ini:/usr/local/etc/php/php.ini
    working_dir: /var/www/html
    ports:
      - "8000:80"
  composer:
    image: composer
    volumes:
      - ./:/app
      - ./docker/web/php.ini:/usr/local/etc/php/php.ini
    working_dir: /app

PhpStorm でリポジトリディレクトリをプロジェクトとして開きます。

1. CLI Interpreter

まず、PHP CLI Interpreter に docker-compose のサービスを指定します。

[Preferences] - [Languages & Frameworks] - [PHP] を開き、CLI Interpreter 右端にある「...」をクリックします。

CLI Interpreters が開くので、左上にある「+」をクリックして Interpreter を選択します。ここでは、一番上にある「From Docker, Vagrant, VM, Remote...」を選択します。

Configure Remote PHP Interpreter が開くので、右端の「Docker Compose」を選択します。Server の横にある「New...」クリックします。

Docker が開くので、「Docker for Mac」を選択して、OK をクリックします。

Server で作成した「Docker」選択さています。Service で、実行する PHP インタプリタ（php コマンド）が含まれるサービスを選択します。ここでは、php-cli を指定しています。

OK をクリックすると、docker-compose run が実行され、自動でコンテナ内の情報を取得します。CLI Interpreters に、取得した PHP や Xdebug のバージョンが表示されます。

OK をクリックすると、CLI Interpreter に作成したインタプリタが表示されます。Path mappings にも docker-compose.yml の volumes で指定している情報が設定されています。OK をクリックして完了です。

2. PHPUnit

PHPUnit を実行できるように設定します。

[Preferences] - [Languages & Frameworks] - [PHP] - [Test Frameworks] を開きます。「+」をクリックして、[Select Configuration Types] から [PHPUnit By Remote Interpreter] を選択します。すると、下記の [PHPUnit By Remote Interpreter] が開きます。

Interpreter に先程作成したインタープリタを選択します。

OK をクリックすると、下記のように CLI Interpreter や Path mappings が設定されます。

PHPUnit が認識できていないので、[Use Composer autoloader] を選択し、[Path to script] に autoload.php のパスを入力します。このパスはコンテナ内のパスなので注意して下さい。ここでは、/var/www/html/vendor/autoload.php を入力しています。入力して、横の更新をクリックすると PHPUnit バージョンが表示されます。

ついでに、phpunit.xml のパスも設定しておきます。[Default configuration file] の左横にチェックを付けて、 /var/www/html/phpunit.xml を入力します。最後に OK をクリックします。

次に、[Edit Configurations]（Run/Debug Configurations）を開いて、左端の「+」から「PHPUnit」を選択します。

Name を任意のものに変更して、[Test Runner] で「Defined in the configuration file」を選択します。

OK をクリックして設定完了です。

PhpStorm ウィンドウ上部にある下記の右矢印や CTRL + R など押すと、PHPUnit を実行できます。

3. Remote Debug

Remote Debug の設定を行います。Remote Debug を設定するには、Xdebug の設定、PhpStorm の設定が必要になります。

3-1. Xdebug の設定

php.ini などで、Xdebug を下記のように設定します。

; xdebug
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.remote_connect_back = Off
xdebug.remote_host = docker.for.mac.localhost

ポイントは、xdebug.remote_host です。以前は、Docker for Mac の問題でコンテナからホストの通信が上手く動作しない場合があったのですが、 docker.for.mac.localhost を指定することで正常に通信できるようになりました。

https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds

サンプルプロジェクトでは、docker/web/php.ini にて設定済です。

3-2. PhpStorm の設定

[Edit Configurations]（Run/Debug Configurations）を開いて、左上の「+」をクリックして、[PHP Remote Debug] を選択します。新しい設定が開くので、[Servers] 横にある「...」をクリックします。

[Servers] が開きくので、左上にある「+」をクリックして、追加します。

[Name] に Docker 、[Host] に localhost、[Port] に 8000 を入力します。つづけて、[Use path mappings] にチェックを入れて、プロジェクトルートディレクトリのマッピング先に /var/www/html を設定します。これにより、ホスト側のディレクトリとコンテナ側のディレクトリをマッピングします。

OK をクリックすると、[Servers] に Docker が指定されています。[Name] に任意の名前、[ide key] にダミーのキーを入力します。なお、[ide key] は、Xdebug の設定で xdebug.idekey を指定している場合はその値を指定します。

これで設定は完了です。

3-3. Remote Debug - Web

Web アプリケーションをステップ実行してみましょう。

[Run] メニューにある [Start Listening for PHP Debug Connections] をクリックして ON にします。これで、Xdebug からの通信を受け付ける状態になります。

PhpStorm ウィンドウ右上にある受話器アイコンをクリックしても ON にできます。（下記は、OFF の状態）

動作確認のために、[Run] メニューにある [Break at first line in PHP Scripts] もクリックして ON にしておきます。これを ON にすると、実行された最初の行で処理が停止し、デバッガが起動します。

この状態で、ブラウザで http://localhost:8000/ を開くとデバッガが起動します。ステップ実行すると順に処理を実行できます。

次は、ブレイクポイントを設定して、処理が停止するか確認します。先ほどの [Break at first line in PHP Scripts] を OFF にしておきます。

routes/web.php の下記の行にブレイクポイントを設定します。ブレイクポイントは、下記の矢印の先あたりをクリックすると設定できます。

この状態で、再度ブラウザを再読込すると該当行で処理が停止します。

PhpStorm のデバッガは優秀で、その時点での変数やスタックトレースなど多くの情報を表示できます。また、条件付きブレイクポイントを設定したり、中断した時点でのコンテキストでコードを実行したりもできます。

3-3. Remote Debug - CLI(PHPUnit)

PhpStorm から PHP スクリプトを実行した場合もデバッガが使えます。

artisan を開いて、下記のようにブレイクポイントを設定しておきます。

この状態で、右クリックして [Debug 'xxxx'] （CTRL + SHIFT + D）をクリックすると、docker-compose 経由で arisan が実行されます。実行がはじまるとすぐにブレイクポイントを設定した箇所で処理が停止し、デバッガが起動します。

PHPUnit でテストを実行する場合も同じ方法でデバッガが使えます。テストケースでブレイクポイントを設定後に、Debug 実行すると、テストが起動して、ブレイクポイントの箇所で処理が停止できます。

さいごに

PhpStorm の Docker サポートは前からあったのですが、docker-compose に対応してなかったり、Docker for Mac 側の問題があったりなどがあり、Vagrant との連携に比べると今ひとつの印象がありました。

改善が進み、それらが解消してきたので、PhpStorm 上からも快適に利用できるようになりました。やはり、IDE から操作できるのは便利ですね。

[参考] Vagrant 連携設定

TDD を体験する本「テスト駆動開発」

2017-10-25T00:00:16+09:00

TDD の原典であるテスト駆動開発が、t_wada さんによって再翻訳されるということで興味を持っていたところ、見本誌を送って頂きました。ありがとうございました。早速、拝読させて頂きました。

以前の翻訳版である「テスト駆動開発入門」が出版された頃、XP 本や他の xUnit 本などは読んだのですが、本書は未読でした。テストをコードで書くことや自動化には興味があったので、おそらく手に取ったことはあったと思うのですが、購入には至りませんでした。

当時は、新しい開発プロセスの一つとしてテストの自動化を捉えていましたが、それを日々の開発で当たり前に行っている中で本書に触れてみてどのように感じるかという視点で読み進めました。

本書は、三部構成となっています。第 1 部と第 2 部では、TDD を実践しながらコードを書き上げていく過程を解説しています。第 3 部は、テストに関する様々な話題がまとめらており、コラム集のようになっています。三部構成とはいったものの、今回加筆された付録 C も内容を考えると一つのパートとも言えるので、実質は四部構成といって良いかもしれません。

TDD でコードが実装されていく楽しさ

第 1 部では、通貨の演算を TDD で実装していきます。本文とコードが分かりやすいように記されているので、まるでライブコーディングを見ているような気分で読んでいきました。

Dollar の演算を実装し、Franc が追加され、相互に変換が加わりといった具合にコードが進化していく様は、まるで物語を読んでいるようで、先の展開が気になり、どんどんページをめくっていきました。最終的に、え、その形で終わり？と思ったところで、TDD を学ぶための例題だったことを思い出したくらいです。

コーディングを見ていく過程で自然と TDD のプラクティスを知ることができるというのは良くできた構成だと感じました。

xUnit の実装

第 2 部では、シンプルなテスティングフレームワークを TDD で実装していきます。日頃利用しているテスティングフレームワークのコア部分を実装するということで、題材としても想像しやすいですし、どのように実現するのか関心を持ちました。

setUp() と tearDown() を Template Method パターンで実装したり、テストスウィートで複数のテストケースをまとめて実行したりと、おなじみの機能の実装が体験できるのはいいですね。

2017 年のテスト駆動開発

今回の再出版に際して、t_wada さんが加筆されたのが、付録 C です。本書が初回出版された以後の TDD 界隈の流れ、そして現在の状況が解説されています。TDD / BDD などの流れが丁寧に記されていて、現在の状況にどのように繋がっているかが分かります。（もちろん、数年前にあった DHH の「TDD is dead. Long live testing.」にも触れられています）

特に、教条主義に触れた箇所はいいですね。TDD の話題では、教条主義的な立場から、これこそが TDD、それ以外は異端といったような意見が見受けられますが、まさにその中心となる本書で、教条主義化について触れられています。

この箇所では、教条主義的に本書や本道とされることのみを良しとするわけでもなく、また、反対に教条主義をただ批判するわけでもなく、現状を把握した上で一歩引いた視点で解説されており、バランスの取れた内容となっているのが、さすがでした。

この章は書き下ろしということで、文体含めて特に読みやすかったです。いつか、t_wada さんが、テストに関する書籍（より実践的な内容を含んで）を執筆されることを期待せずにはいられません。

写経

通読の後、Part1 と Part2 について写経を行いました。TDD は、当然ながら言語に依存するようなものではないので、PHP で実装してみました。リポジトリには、Makefile があるので、make コマンドで、依存解決とテスト実行ができます。

github.com

本書にもあるとおり、写経で実際にコードを書いてみると、また異なる印象を受けますね。特に、Part1 では、かなり歩幅を落として、小刻みにサイクルを回していくので、日頃の開発でテストを書くのとは異なるリズムで進めることになりました。これほど小さな歩幅でサイクルを回して進めることは無いので、これは面白い体験でした。

このスピード感の違いや違和感（自分のリズムとは違うという意味で）は、実際にコードを書いてみて、より感じる部分なので、本書を手にした方はぜひコードを書いて体験してみてください。

実は、見本誌（紙）とは別に電子版（PDF）を購入して、併用で読み進めたのですが、写経の時は紙の方が見開きで見ることができるのでやりやすかったです。

TDD はテスト技法では無い

皮肉なことに、TDD はテスト技法ではない。TDD は分析技法であり、設計技法であり、実際には開発のすべてのアクティビティを構造化する技法なのだ。

「テスト駆動開発」

本書を読む上で、また TDD を知る上で重要なのは、これですね。もちろん書籍内では、テストの書き方についても解説されていますが、テスティングフレームワークの機能を活用して、いかにテストを効率的に書くかという視点の書籍では無いと感じました。（ただ、実際のところ、テスト技法を知る本としての役割も果たしています。）

つまり、TDD を行うかどうかという話とテストを書くか書かないかは別ということです。

原著が登場した頃は、まだテストを書く文化がそれほど一般的ではなかったと思うので、このあたりが混同されがち（自分を含めて）だったと思うのですが、テストを書くということが一般化した今なら、テストで開発を推し進める TDD という開発技法がより正しく伝わるのではないでしょうか。

そういった意味では、2017 年の今に本書が登場したというのは何か意味があるようにも感じます。

さいごに

本書で感じた TDD の小気味の良いリズム感は気持ち良いものでした。日々の開発を TDD で行うかは別にしても、思ったように開発が進まない時や実装が難しいような場合に使える手法として持っておくと良いですね。

ときおり、開発を始める前の肩慣らしのように TDD で軽くコードを書いてみるというのも良さそうです。

テストを書いている人はもちろんのこと、テストを書いていなくとも開発手法に興味がある人は、ぜひ本書で TDD を体験してみてください。

テスト駆動開発

作者: Kent Beck,和田卓人
出版社/メーカー: オーム社
発売日: 2017/10/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

「型を意識した PHP アプリケーション」を発表しました / PHP カンファレンス 2017

2017-10-11T06:00:00+09:00

PHP カンファレンス 2017 にて「型を意識した PHP アプリケーション」を発表してきました。

発表

github.com

型宣言が付いていないコードに、スカラー型の型宣言、ドメインに特化した型の型宣言と型（クラス）の実装を行うライブコーディングをメインにしました。

ライブコーディングの部分は動画を見た方が分かりやすいです。下記の 13:00 頃からコーディングがはじめるので、こちらも合わせてどうぞ。

きっちりまとめられた資料をベースに発表するのも良いのですが、実際にコードを書いていくのを見た方がイメージも伝わりやすいですし、私自身も人がコードを書く様を見るのが好きなので、この構成にしました。

また、質疑応答の時間を長めに取りたかったので、本編は少し短めにして時間が余るように調整しました。当初の内容からどんどん引き算していって、内容をシンプルにしたので、結果的には進めやすかったですし、何より質疑応答で多くの質問を頂けたので良かったです。

やっぱり、せっかくのライブなので、一方通行よりキャッチボールできるのが楽しいです。メインの発表中もやりとりしながら進められる形ができるといいですね。

Twitter での反応では概ね好評だったようなので発表して良かったです。tweet ありがとうございました！

togetter.com

「PHP の現場」

ここ最近の発表では自己紹介で「PHP の現場」を紹介して、聴いたことがあるかを聞いています。PHP カンファレンス関西、builderscon 、PHP カンファレンスと続いた中では今回が一番多くの方に手を上げて頂きました。

発表後も会場で、何名かの方に「聴いてます！」と声をかけて頂きました。

特に印象的だったのは、聴いたエピソードについて話を振ってくれる方が多かったということです。エピソードの内容は、基本私が聞きたいことなので、自然と会話が盛り上がりました。自分が面白いと思ったことを共感してもらえ、さらにそれをネタに会話が広がるというのは本当に嬉しいことです。（もちろん、ただ聴いてますと言って頂けるだけでも嬉しいです！）

あらためて、聴いて頂きありがとうございますm(_ _)m

今後もイベントなどで会う機会があれば、声を掛けて頂ければ嬉しいです。

さいごに

今年も PHP カンファレンスは最高でした！これだけの規模のイベントは本当に大変だと思いますが、スタッフの皆さんには感謝するばかりです。今年も楽しいイベントをありがとうございました。

来年は、12 月ですね。冬の PHP カンファレンスは個人的には初めてな気がするので、どんな感じにするのか楽しみです。

さいごに 2

せっかくカンファレンス熱が高まったところなので、次回の PHP の現場では技術系カンファレンスについて話す予定です。お楽しみに。

php-genba.shin1x1.com

PHP カンファレンス関西 2017 にて基調講演をしました

2017-07-18T00:00:00+09:00

PHP カンファレンス関西 2017 の基調講演にてお話してきました。

発表資料

今回は、開発現場から見た PHP の特徴をあらためて見直すということで、私が日頃感じている特徴をお話しました。最後には現場で奮闘している PHP エンジニアへのメッセージを入れました。

朝一番のセッションにも関わらず、立ち見が出るほど多くの方に参加頂き、嬉しい限りでした。参加頂いたみなさん、ありがとうございました。

資料だけでは伝わらない部分もありますが、資料を上げておきます。

終わり際にある「繋ぐ言語」というのは、2014 年基調講演された郡山さんの「全てを結ぶ力」へのオマージュだったりします。発表後に会場でご本人に伝えるとがっちり握手して頂けました :)

基調講演

これまで、招待講演も基調講演を招く側も経験していたのですが、基調講演で話すというのは初めての経験でした。

はじめは、いつもの発表のノリで軽く受けたのですが、いざ準備してみると、あれこれ考えてしまい、そもそも基調講演とは？という根源的な問いかけを自身にしながら模索していました。誰に何を伝えるのかという考えるのかがグルグルと周り、二転三転した結果、今回の内容になりました。

PHP カンファレンス関西では、過去に 6 人の方に基調講演をして頂いて、セッション担当としてアテンドしていたのですが、これまで皆さんがやってこられた準備や葛藤が分かり、改めて感謝を感じています。ありがとうございました。

さいごに

2011 年に PHP カンファレンス関西を立ち上げて以来、第 1 回、第 2 回は実行委員長、以降はスタッフとしてこのイベントに関わってきたので、1 スピーカーとして参加した最初の PHP カンファレンス関西でした。

こうして自分をはじめ立ち上げ当初にいたメンバーが抜けていっても、ちゃんとイベントが回っているというのは嬉しい限りです。実行委員長のショウノさんをはじめ、スタッフの皆さん、楽しいイベントをありがとうございました！

DI（Dependency Injection）に関するメモ

2017-05-20T14:24:20+09:00

PHPの現場にて、DI 談義を行うので、頭を整理しておくためのメモです。

DI についてきちんと知りたいのであれば、参照に挙げたリンク先に有用な記事があるので、そちらを参考にして下さい。

PHP を念頭に置いてますが、Java など他言語でも大枠は同じだと思います。この内容は、いずれ整理するかもしれませんし、そのままかもしれません。

DI という言葉

「DI」が差す意味合いが、依存オブジェクトの注入だけなのか、DI コンテナによる注入を含んでいるのか、DIP まで意識しているのかが、人やコンテキストによって違っていそうで、そこを揃えてから議論しないと。
— Masashi Shinbara (@shin1x1) May 19, 2017

DI について話す時に、何を差すのかが異なると話が噛み合わない。そこで、それぞれに名前を付ける。

DI パターン = 依存オブジェクトを注入することを差す。DI コンテナを利用するかどうかは問わない。（GoF の Strategy パターン）
DI コンテナ = DI パターンを実現するために便利なライブラリ。依存オブジェクトの生成、注入、ライフサイクル管理*1を行う。フレームワークに内包されていることもある。

DIパターンの適用範囲は広く、PHP でも型宣言（タイプヒント）を用いて型を指定する場合はもちろんのこと、型宣言が無い場合や無名関数を与える場合も DI の一種と言える。

実際、AngularJS では、型を指定しない（TypeScript など使えば型指定可能）が、DI を利用している。

「DI = DI コンテナの利用」ではない。DI コンテナを使わなくても、DI パターンの実現は可能。
型指定が無くても、DI できる。

DI パターン

DI パターンでは、依存オブジェクトを型で指定するのが一般的だ。型の指定は、下記の順で、より結合度が低くなり、依存が明確になる。

型指定無し
具象クラス
抽象クラス
インターフェイス

このあたりは、DI に限らず、インターフェイスをなぜ利用するのか？具象クラスだけで良いのでは？という議論にも発展できる。

DI パターンのメリット

クラス間を疎結合にする。（結合度を下げる。）
それぞれが独立したモジュールになり、自身の役割のみに専念できる。（凝集度が高くなる。）
クラスの役割が明確で、限られたものになるので、実装しやすく、テストもしやすく、利用しやすくなる。（脳に優しい）
必要な依存が明確になる。
インターフェイスに依存した場合、インターフェイスの API のみが依存箇所なので、それ以外の部分（API の実装や与えられたインスタンスが持つ他のメソッドなど）は一切気にする必要がなくなる。（脳に優しい）

DI パターンのデメリット

ファイルが増える。
実装を追いにくくなる。（結局は実装読まないと分からないでしょ）
インターフェイスに依存とか言ってるけど、PHP だと与えられたインスタンスのメソッドは何でも呼べてしまう。（IDEでは警告は出るが、実行はできる）

依存オブジェクトの注入

依存オブジェクトを注入するには、下記のような方法がある。

コンストラクタインジェクション
セッターインジェクション（インターフェイスインジェクション）
フィールドインジェクション
メソッドインジェクション

どの方法でも実現はできるが、コンストラクタインジェクションが推奨されている。

インスタンス生成のシーケンスで依存オブジェクトを注入できる。特殊な操作が不要。
インスタンスが生成されたときには、依存オブジェクトは注入済なので、安全に利用できる。
コンストラクタでのみ注入できるので、インスタンスにどのような操作を行っても、外部から依存オブジェクトを差し替えられて、想定外の動きをするなどを防ぐことができる。

このあたりの利点は、完全コンストラクタとも似ている。

DI コンテナ

依存オブジェクトをアプリケーション自ら与えることで、DI パターンは実現できるが、実際のところ、DI コンテナを利用するのが一般的だ。

PHPには、数多くの DI コンテナがある。Web アプリケーションフレームワークを利用している場合、内包されていることが多く、意識せずに利用しているかもしれない。

PHP の主な DI コンテナは以下。

PHP では、PSR-11 にて DI コンテナの API が規定されている。

fig-standards/PSR-11-container.md at master · php-fig/fig-standards

ワイヤリング

DI コンテナは、依存オブジェクトの生成（取得）方法を知っておく必要がある。これには、ファクトリ（クラスや無名関数等）や設定ファイル（YAML や XML）を利用する。

ただ、全ての生成方法を指定していくのは骨が折れる作業なので、あらかじめ決められたルールや最低限の設定で自動でオブジェクトを生成する auto-wired という仕組みがある。

例えば、Laravel の DI コンテナでは、型宣言に具象クラスを指定すれば、ワイヤリングの設定が無くとも、new でインスタンスを生成する。また、インターフェイスの場合は、対応する具象クラスを設定しておけば、そのインスタンスを生成する。

DI コンテナとサービスロケータ

DI コンテナと比較して良く登場するのが、サービスロケータだ。これは、オブジェクトコンテナを依存として注入し、利用時に必要な依存オブジェクトをこのコンテナから取り出すというパターンである。

サービスロケータは、DI を使わずに依存オブジェクトを内部で生成するパターンの発展系で、一方、DI コンテナは、外部から依存オブジェクトを与えるので、制御の方向が逆とも言える。

サービスロケータでも、DI コンテナと同様に、実装の差し替えや依存オブジェクトの生成やライフサイクルの管理といったメリットを享受できる。

ただ、DI パターンのメリットである、依存を明確にする、最小限にするという効果は薄れる。

このあたりは、何を求めて利用するのかという目的によって使い分けると良い。（サービスロケータが全てダメとかいう短絡的な話ではない）

PHP で DI が必要か？

PHPでDI流行ってるの、便利なんだけどもやもやはしている。もっと密結合でいいじゃん、という。
— Hiroyuki Yamaoka 🐰 (@hiro_y) May 18, 2017

収録分を公開しました。

7. PHP に DI は必要か？（hiro_y / ytake） | PHPの現場

参照

*1:HTTP リクエスト単位で全てを破棄する PHP では、オブジェクトのライフサイクル管理の重要性は他言語とは異なる。

WordPress Way を知る本「エンジニアのための WordPress 開発入門」

2017-03-10T00:00:00+09:00

著者の杉田さんに献本して頂いたので拝読しました。

PHP エンジニアのための WordPress 本

タイトルにあるとおり、普段フレームワークなどを使って Web システムを開発している PHP エンジニアのための WordPress 本です。

ユーザとして WordPress を利用するのではなく、PHP エンジニアとしてどのように扱うのか、どのように付き合うのか視点で書かれているので、興味深く読むことができました。

序盤で、おおっと思ったのが、第 2 章です。WordPress のインストールにの次に紹介されているのが、いきなり、WP_DEBUG をはじめとしたデバッグモードに関する定数、Debug Bar プラグイン、コマンドラインツールの WP-CLI、そして開発用仮想環境を構築する VCCW という流れになっています。

PHP エンジニアが、WordPress を触るための環境構築といった感じで、このあたりからも誰に向けた本なのかが分かります。

個人的には、さらに PhpStorm 上で WordPress を触るための設定などに進んでいくと、グッときますね :)

第5章 WordPress の基本アーキテクチャ

本書のキモとなるのは、第5章の「WordPressの基本アーキテクチャ」でしょう。

WordPress のファイル構成、データ構成（データベーステーブル）、基本処理の流れ、HTTP リクエストパラメータの扱い、フックの仕組みなどベースとなるアーキテクチャが解説されています。

これらを知らずとも WordPress は利用できまずが、ブラックボックスとして扱うより、基本的な流れを把握して利用すれば動作を想像することができ、問題解決やプラグインによる拡張を行う際に大きな助けとなるでしょう。

まず、この章を読んで全体を把握してから、知りたい箇所を各章で補っていくのが良さそうですね。

WordPress と向き合うための本

WordPress は、歴史の長いプロダクトのため、現在行われている PHP 開発とは異なる流儀でコードが実装されています。

コードを読んだ人がまず感じることが、まさに本文に書かれています。

ところが、率直のところ、WordPress のソースコードは美しいとはとても言えません。重要なメソッドや関数が恐ろしいほどの行数だったり、驚くほどたくさんのグローバル変数が定義されていたりします。

こうした WordPress のコードを見た時に感じた違和感をはっきりと明言しておき、それを前提としてどう向き合うのかという視点が本書のユニークなところです。

これは本書に随所で見られる視点で、WP_Query が 4,000 行超あることが書かれていたり、サンプルコードに global キーワードがあったり、グローバル変数一覧がまとめられていたりします。

「言いたいことは分かった。ただ、WordPress のコードを向き合うなら、こうしよう。」

と言ってくれているような気がします。

さいごに

「郷に入っては郷に従え」というのは、フレームワークでも言語でもプラットフォームでも良く言われていることです。

WordPress で開発するなら、まずは WordPress Way に従うのが良い方法で、本書にはその方法がまとめられています。WordPress Way を知るには大きな足がかりになる貴重な本です。*1

開発で WordPress を活用する人はもちろんのこと、WordPress の内部構造や動きに興味がある方にもおすすめです。

エンジニアのためのWordPress開発入門 (Engineer's Library)

作者: 野島祐慈,菱川拓郎,杉田知至,細谷崇,枢木くっくる
出版社/メーカー: 技術評論社
発売日: 2017/01/26
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

*1:個人的には、WordPress はブラックボックスにして、WP REST API で触るというのも面白いと思いますが、その視点でも本書は役立ちます。

「PHPの現場」という Podcast をはじめます

2017-03-02T00:00:00+09:00

学生の頃からラジオを聞いて育ってきたので、技術系のPodcastが好きで色々と聞いています。日本語で PHP 界隈の話題について話すPodcastが無かったので、はじめてみることにしました。

「PHPの現場」というPodcastです。

PHP がメイントピックにはなりますが、PHP の開発現場で出てきそうな話題なら、それ以外の技術や話題についても扱っていくつもりです。

私がお話したいゲストの方をむかえて対談（雑談）形式でざっくばらんに話していきたいので、色々な方にお声がけしていこうと思います。その際は、よろしくお願いしますm(_ _)m

Podcast配信環境

Podcastを配信する上で、どうしようかと迷ったのは配信環境です。

SoundCloud などのサービスを利用することも考えたのですが、どうせなら作ってしまおうと思い、自作しました。（実は、過去にPodcastの配信を行ったことがあり、その時も自作（GAE+Python）していました。）

Podcast配信サーバは、ようは RSS フィード配信とオーディオファイル配信（Range Requests 対応）ができれば良いので実装は難しくありません。ただ、配信 RSS の内容を調整したり、どうせ趣味で作るならとあれこれいじっていたら、思ったより時間がかかってしまいました。

音源はあるのに、配信サーバの調整に時間をかけるという本末転倒な状況でしたが、久しぶりに趣味の Web サービスを作ったので、空き時間に楽しんで作業していました :) 自由にできるアプリケーションがあるのはいいですね。

技術要素としては、以下のような感じです。

Digital Ocean
Docker / docker-compose
PHP 7.1 + Slim 3
papertrail（サーバ、Docker コンテナのログを集約）
Google Analytics（Web アクセス、RSS / オーディオファイルダウンロード実績を集約）
Mackerel（サーバ監視）

開発でも本番でも docker-compose でコンテナを起動するだけなので、インフラはその時々の状況でよしなに移動できます。

今回の実装でアプリケーション仕様は固まったので、今後は気が向けば別言語で再実装して遊ぶのもいいですね。

初回配信

初回は、下記エントリに書いた「Podcast で話すような感じでやる発表」を実現した昨年末の関西 PHP 勉強会の模様を配信しています。

blog.shin1x1.com

@tanakahisateru さんと例外について話しました。

この回は、年末ということもあり、乾杯の後に発表をはじめた、くだけた雰囲気でした。途中、二人以外にも話に入ってきたりして、楽しかったです。配信を聞かれる方は、そういった雰囲気での話というのをイメージして下さい :)

さいごに

まだ手探り感が満載ですが、はじめて見ないことには分からないので、少しづつやっていこうと思います。

感想や要望などあれば、 #phpgenba で tweet して頂けると嬉しいです。

それでは、「PHPの現場」よろしくおねがいしますー！

PHPの現場

Masashi Shinbara
テクノロジー
¥0

openssl_encrypt() による PKCS#7 パディング

2017-01-12T10:40:00+09:00

PHP の openssl_encrypt() にて、ブロック暗号による暗号化を行うと PKCS#7 パディングが行われます。この動きを確認してみます。

http://php.net/manual/ja/function.openssl-encrypt.php

PKCS#7 パディング

ブロック暗号では、決められたブロック長を単位として暗号化を行います。対象となる平文がブロック長の倍数の長さであれば良いのですが、そうではない場合、不足分を補う必要があります。これがパディングです。*1

PKCS#7 パディングは RFC 5652 で定義されたパディング方式です。補ったバイト数を 1 バイトの値として埋めます。例えば、3 バイトを補うのであれば、0xXXXX030303 のように 3 が 3 つ並びます。PKCS#7 では、1 バイトで不足バイト数を示すので、1 - 255 バイトまでを補うことができます。

01     <--- 1 バイト分
0202   <--- 2 バイト分
030303 <--- 3 バイト分

https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS7

これと似た動きをするのが、PKCS#5 パディングで、こちらは 8 バイトを倍数とした場合のパディングを行います。つまり、取り得る値は 1 - 8 となります。

余談ですが、Java の javax.crypto.Cipher にある PKCS5Padding は、名前は PKCS5 ですが、実質は PKCS#7 相当の動きをするようです。

他のパディングには、0 で埋めるゼロパディングなどがあります。

openssl_encrypt() によるパディング

openssl_encrypt() のデフォルトでは、PKCS#7 パディングが行われます。

この動きを見ていくためのサンプルが以下です。このサンプルでは、openssl_encrypt() で暗号化、openssl_decrypt()で復号を行っています。

ここでは、AES（Rijndael）を利用しているのでブロック長は 128bit（16バイト）です。平文は plain の 5 バイトなので、不足分の 11 バイトがパディングで埋められます。

<?php
$plaintext = 'plain';
$key = hash('sha256', 'this is a secret key.');
$method = 'aes-256-cbc';
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length($method));

$encrypted = openssl_encrypt($plaintext, $method, $key, 0, $iv);
printf("encrypted: %s\n", $encrypted);

$decrypted = openssl_decrypt($encrypted, $method, $key, 0, $iv);
printf("decrypted: %s\n", $decrypted);

これを実行すると下記のような出力になります。暗号文はデフォルトで base64 エンコードされています。復号した結果を見ると元の平分が出力されています。ここではパディングが見えないですが、これは openssl_decrypt() にて復号時にパディングを除去するためです。

encrypted: vGZiiLXzuiGnOBkJbWAiHw==
decrypted: plain

暗号文にパディングが含まれているかを確認するために復号時に OPENSSL_NO_PADDING を指定して、パディング除去が行われないようにします。

<?php
$plaintext = 'plain';
$key = hash('sha256', 'this is a secret key.');
$method = 'aes-256-cbc';
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length($method));

$encrypted = openssl_encrypt($plaintext, $method, $key, 0, $iv);
printf("size: %d bytes\n", strlen(base64_decode($encrypted)));

$decrypted = openssl_decrypt(base64_decode($encrypted), $method, $key, OPENSSL_RAW_DATA | OPENSSL_NO_PADDING, $iv);
printf("decrypted: %s\n", bin2hex($decrypted));
printf("size: %d\n", strlen($decrypted));

これを実行したのが下記です。

パディングが見えるように復号した結果は bin2hex() で出力しています。前半の 706c61696e の部分は平文の plain です。それにつづく 0b が 11 回連続している箇所がパディングです。ブロック長 16 バイトから平文の 5 バイトを引いた 11 バイトがパディングとなるので 0x0b が 11 回連速しています。

復号した結果は 16 バイトとなっており、これもブロック長と一致します。

encrypted: iwBv6P3euwwdct8DHutBNA==
decrypted: 706c61696e0b0b0b0b0b0b0b0b0b0b0b
size: 16

平文サイズがブロック長と一致している場合

では、平文サイズがブロック長と一致している場合はどうなるでしょう。

平文を plainplainplaina の 16 バイトにして実行したのが下記です。

復号結果は、なんと 32 バイトになりました。内容を見ると 10 が 16 回連続しています。これは、ブロック長分のパディングです。つまり、1 ブロック分が追加されているわけです。

平文の後にはパディングが付いていることを前提とするため（そうでないと平文なのかパディングなのか判断できない）にこのような動きになっているのでしょう。

encrypted: PFZ8G+XYhs9x22aP/a7Jy88eQJv6GVaKMXrBfq5/bGU=
decrypted: 706c61696e706c61696e706c61696e6110101010101010101010101010101010
size: 32

さいごに

openssl_encrypt() によるパディングを見てきました。

デフォルトのまま、openssl_encrypt() で暗号化し、openssl_decrypt() で復号するならパディングを意識する必要はあまりありません。

しかし、別システムで暗号化されたものを復号したり、その逆の場合は、どのような形式でパディングを行うのかというのは共有しておく必要があります。

参照

https://www.openssl.org/docs/man1.1.0/crypto/EVP_EncryptInit.html

*1:実際には、後述するとおりブロック長倍数であってもパディングが追加されます。

アプリケーションから例外を投げる派、投げない派

2016-12-27T00:37:24+09:00

例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。

基本の考え方

ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。

例外的な状況の時にのみ例外を使う。

Effective Java

禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。

人によって異なるのは「例外的な状況」の解釈です。

例外的な状況

この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。

1. アプリケーションから独自の例外を投げる派

ランタイムやミドルウェア連携などプラットフォーム起因のエラーだけではなく、アプリケーションやドメインにおけるエラーを例外としてスローする派です。例外クラスも必要に応じて定義します。

例外をエラー処理に積極的に利用する考え方ともいえ、例えば、入力値におけるバリデーションエラーやドメインロジックのエラーにおいても例外を利用します。

2. プラットフォームやフレームワークが投げる例外以外は使わない派

ランタイムやミドルウェア連携などプラットフォーム起因のエラーなど深刻なエラーでのみ例外を利用し、アプリケーションにおけるエラーにおいては例外を利用しない考え方です。

この考え方の人の中には、例外クラスはアプリケーション独自で定義せず、アプリケーションからは例外をスローしない（ランタイムやフレームワーク、ライブラリからの例外のみ扱う）という意見もありました。

アプリケーションのエラーは、戻り値で通知することになります。（特殊な値（null や false）を使ったり、原因別に戻り値を返すなど）

アプリケーションから独自の例外を投げる派の意見

私は、前者の「例外を積極的に使う派」です。理由としては、下記のようなメリットを感じています。（なお、ここでは PHP を対象として、検査例外のことは考えていません。）

[実装][利用] エラー処理を例外に統一できる。
[利用] 呼び出す側は例外だけ対応すれば良い。（catch する / 対応しない（上位にスロー））
[利用] どのレイヤでエラー処理するかを呼び出し側が選べる。（上位レイヤに伝播できるので、フレームワークの統一的なエラー処理に任せてしまうなどが簡単）
[実装] エラー時は例外を投げれば良いので、ガード節の代わりにもなる。
[実装] テストでは、@expectedException でテストを書けば良いので、何のテストか分かりやすい。（正常時は例外飛ばないので）
[利用] try / catch を書けば、try の中は正常系、catch の中は異常系と処理が分かれて分かりやすい。
[利用] 戻り値のエラー判定が不要。例外が飛ばなければ正常終了と判断できる。
[利用] 例外クラスが持つ情報量が多い。（特にスタックトレース）

さいごに

例外については、人それぞれ思いがあるようで、議論になりやすいところです。この機会に色々な人の意見を聞いてみたいですね。

今日開催の関西 PHP 勉強会でも、話しましょう。

https://kphpug.doorkeeper.jp/events/55554

EFFECTIVE JAVA 第2版 (The Java Series)

作者: Joshua Bloch,柴田芳樹
出版社/メーカー: 丸善出版
発売日: 2014/03/11
メディア: 単行本（ソフトカバー）
この商品を含むブログ (10件) を見る

追記

Twitter へ頂いたコメントをまとめました。色々な意見がありますね。

togetter.com

はてぶでも多くのコメントがあったので、こちらも追記。

b.hatena.ne.jp

子どもの iPhone SE に行った設定リスト 2016年12月

2016-12-22T00:00:00+09:00

子ども（13 才以上）用に iPhone を購入したので、セットアップしたメモです。

iPhone

IIJmio を利用するために、Apple Store で SIM フリーの iPhone SE を購入しました。

www.apple.com

SIM

私が、IIJmio を利用していて、何ら不都合が無いので、同じく IIJmio にしました。連絡は、LINE（チャット or 電話）で行うつもりなので、データ通信専用 SIM を申し込みました。

3GB プランで、900円/月です。（後述する i-フィルター for マルチデバイスを申込んだので、+ 360円）

www.iijmio.jp

ペアレンタルコントロール（機能制限）

利用できるアプリやアクセス先を制限できる機能です。必要な箇所を設定しました。

support.apple.com

Apple ID

利用者が、13 才未満なら子ども用の Apple ID が作成できます。

support.apple.com

今回は、13 才を超えているので、Google アカウントを作成し、Gmail のアドレスで、Apple ID を取得することにしました。

Google アカウントを作成 https://accounts.google.com/SignUp?hl=ja
Apple ID を作成 https://appleid.apple.com/account?localang=ja_JP#!&page=create

インストールするアプリを許可制にする

iCloud のファミリー共有を使えば、子どもが自由にアプリをインストールすることができなくなります。アプリをインストールすると、親（管理者）へ承認を求めるようになります。承認が要求されると、親の iOS デバイスに通知が来て、ここで許可 or 拒否を指定できます。

www.apple.com

support.apple.com

ファミリー共有すると、家族の端末にインストールしたアプリや現在位置を管理者の端末で確認できます。反対に管理者の情報を家族の端末で見ることもできますが、どの情報を共有するかは ON / OFF できるので、管理者のものは共有しないことも可能です。

support.apple.com

Apple Music

Apple Music を家族で利用できるようにします。すでに個人メンバーシップには登録していたので、これをファミリーメンバーシップに切り替えて、子どもの Apple ID を招待しました。

support.apple.com

LINE

LINE アカウントを作成するには電話番号か Facebook アカウントが必要になります。今回は、データ通信のみの SIM にしたので、Facebook アカウントを作成しました。

Facebook https://www.facebook.com

LINE アプリをインストールして、「Facebook アカウントでログイン」を選ぶと、Facebook連携でアカウントで LINE アカウントが作成できます。

official-blog.line.me

あと、意図せず友達申請が来たりするのを防ぐために幾つか設定しておきます。

プロフィール - 「IDで友達追加を許可」を off（年齢確認できていないので、off のはず）
プライバシー管理 - 「メッセージ受信拒否」を on （友達以外からのメッセージ受信を拒否）
友だち - 「友だち追加」を off （アドレス帳の連絡先を自動で友だちに追加しない）
友だち - 「友だちへの追加を許可」を off （電話番号を保有している LINE ユーザが自動で友だち追加したり、検索できるのを拒否）
タイムライン - タイムラインは使わなくて良いけど、もし使うなら「友だちの公開設定」「新しい友だちに自動公開」を確認。

i-フィルター for マルチデバイス

フィルタリングソフトを一応導入しました。まだ、どれほど活用できるかは分からないですが、やってみて、不要なら解約する予定です。

www.iijmio.jp

さいごに

メールアドレスも無い、Apple ID も無い状態から iPhone を設定したのは、はじめてなので思ったより手間取りました。

ある程度慣れている人なら調べながら自分でできますが、詳しく無い人だとほんと大変ですね。

格安 SIM を利用する人が増えていますが、3 キャリアにはこうしたセットアップを店舗でサポートしてくれるサービスがあるので、月々の通信費は割高でも、サポートが必要な人にとってはそちらの方が良いのかもしれません。

はじめに手にした iPhone 。大事に使って、良い思い出を作っていって欲しいものです。

公開 Podcast のような勉強会セッションをやってみる

2016-12-20T00:00:00+09:00

勉強会の企画を考えるとき、あの人からあの話聞きたいなというのがあって、普通なら登壇を依頼すればいいんだけど、準備も大変だろうから、あの話の blog エントリや過去のスライドを前に出して、インタビュー形式で「ここ教えて下さい」みたいな感じでやるセッション案。
— Masashi Shinbara (@shin1x1) 2016年12月19日

動機

内容が大事で、それが聞きたいだけなのに、スライド作ってとか表現への準備が大変。
技術系勉強会では、スライドを作ることは本質ではない。（内容が伝われば手段は何でも良い）
かといって、登壇する時にスライド無しで一人で話すのも大変。
運営としても、発表者としても前々から解決したいテーマだった。
Podcast は、音声だけだが、十二分に伝わる。緩い雰囲気も聞きやすい。
あ、これだ！

考えていること

話し手と聞き手がいて、二人が話すのをみんなで見る。
話し手が、公開しているコンテンツ（blog、発表スライド、OSS、tweet 等々）をベースに話していく。
話し手は、過去に公開したものがベースなので、スライド作るより準備が楽。当日も聞き手がいる方が話しやすい。
場合によっては、コード書いて見せたりするのもあり。
聞き手は、事前に質問を考えておく必要がある。負担を双方で受け持つ。

@shin1x1 お願いした後、投げっぱなしではなくてお願いする側に負担があるのは良いですね！「質問事項は私の方で考えるので宜しくお願いします！！」って依頼しやすいです^^ あとディスカッション形式の方が本音聞けそう！（なんとなくですがｗ）
— ☯Takashi Hosoya（細谷崇） (@tkc49) December 19, 2016

期待していること

聞きたいことを聞きたい人に負担を少なめで聞ける。
懇親会で話すような雰囲気でくだけた話をしたい。（「懇親会が本番」を本編で）
参加している人も、二人が対話している方がリラックスして聞きやすいし、入りやすいのでは。
間があってもいいし、二人いるから、どちらかが話せば良い。
パネルディスカッションに比べると、各人に話を振っていく必要が無いから楽。

さいごに

こんなセッションを 12/27 開催の関西 PHP 勉強会でやってみます。

第36回関西PHP勉強会 - Kansai PHP Users Group | Doorkeeper https://kphpug.doorkeeper.jp/events/55554

どうせなら、録音して Podcast とかで出せるといいかなとかも考えてますが、予定は未定なので、ご都合が付く方は参加お待ちしています！

Amazon Dash Button にみるドメイン特化クラスのヒント

2016-12-07T15:00:00+09:00

この投稿は、PHP Advent Calendar 2016 - Qiita の 7 日目です。

DDD のようなドメインを意識した開発手法でなくても、ドメインコンテキストで必要な操作のみを実装したクラスを作ってみましょう話です。

Amazon Dash Button

Amazon Dash Button は、ボタンが一つだけあるデバイスです。このボタンを押すと、あらかじめ決められた商品の注文が Amazon に送信され、商品が配送されるというシンプルなものです。

このデバイスは、「商品を届けて欲しい」というユースケースに対して、ボタンを押すというシンプルなインターフェイスを実装しています。単にボタンを押すだけなので、その裏側でどのようにして実現されているかを知らずとも、誰もが利用できます。違う言い方をすれば、ボタンを押す（商品を注文する）ことしかできないので、操作方法を覚える必要もなく、想定外の使い方もやりようがありません。*1

このように、ドメインやそのユースケース、関心事に特化したインターフェイスを用意すれば、そのコンテキストの中では迷うことなく、自然に理解でき、扱い方を間違えることもありません。

ドメイン特化クラス

「ユーザに現在の年齢を尋ねる」というユースケースの実装を考えてみます。

User クラスとして実装したのが、下記です。

現在の年齢を算出するには、生年月日が必要となるので、コンストラクタで渡しています。生年月日は、cakephp/chronos パッケージの Date クラスで表現しています。

年齢を尋ねるには、age メソッドを利用します。

<?php
namespace Acme\Generic;

use Cake\Chronos\Date;

class User
{
    /**
     * @var Date
     */
    private $dateOfBirth;

    /**
     * @param Date $dateOfBirth
     */
    public function __construct(Date $dateOfBirth)
    {
        $this->dateOfBirth = $dateOfBirth;
    }

    /**
     * @return int
     */
    public function age(): int
    {
        return $this->dateOfBirth->age;
    }
}

このコードを実行するのが、下記です。生年月日をコンストラクタを渡して、age メソッドを呼ぶだけなのでシンプルです。

<?php
// 現在日を設定
// Chronos::setTestNow(Chronos::create(2016, 12, 8, 12, 34, 56));

$user = new User(Date::create(2000, 1, 1));
echo $user->age(), PHP_EOL; // 16

このままでも動作は問題は無いのですが、気になるのは、Date クラスです。これは、日付を扱うクラスなので、挙動としては問題ありません。ですが、このクラスは汎用クラスなので、ドメインのコンテキストで扱う生年月日ではありません。プロパティ名を見れば、生年月日であることは想像できますが、より明示するために生年月日を示すクラスを実装します。

生年月日を示したのが、下記の DateOfBirth クラスです。内部表現としては、Date クラスを利用しているので、ただのラッパーのようにも見えます。ここで大事なのは、Date クラスのインスタンスを内包して、DateOfBirth クラスでは、年齢を算出する age メソッドのみを実装しているという点です。これにより、DateOfBirth クラスが担うのは、年齢を算出するだけということが分かります。

<?php
namespace Acme\Domain;

use Cake\Chronos\Date;

class DateOfBirth
{
    /**
     * @var Date
     */
    private $date;

    /**
     * @param Date $date
     */
    public function __construct(Date $date)
    {
        $this->date = $date;
    }

    /**
     * @return int
     */
    public function age(): int
    {
        return $this->date->age;
    }
}

DateOfBirth クラスを使った User クラスは下記です。コンストラクタの型宣言が変わっているだけなのですが、Date クラスに比べると生年月日であることが読み取れます。もちろん、User クラス内で生年月日を操作する際も age メソッドしかできないので、間違いようがありません。

もし、配送日などの別の日付クラスが存在したとしても、誤って User クラスに与えることができません。要求されている仕様が分かりやすいだけでなく、誤った引数に対するガードとしても有効です。

<?php
namespace Acme\Domain;

class User
{
    /**
     * @var DateOfBirth
     */
    private $dateOfBirth;

    /**
     * @param DateOfBirth $dateOfBirth
     */
    public function __construct(DateOfBirth $dateOfBirth)
    {
        $this->dateOfBirth = $dateOfBirth;
    }

    /**
     * @return int
     */
    public function age(): int
    {
        return $this->dateOfBirth->age();
    }
}

ドメイン特化クラス実装のポイント

このようなドメインに特化したクラスを実装するには色々な方法がありますが、いくつかポイントを書きます。

操作を必要最低限に絞る

PHP には、数多くの組み込みクラスやライブラリ、フレームワークがあります。一般的なデータ型を示すためのクラスは探せば見つかると思うので、多くの場合、それをベースとして利用するでしょう。

その場合、継承ではなく上記の DateOfBirth クラスのように委譲を使って実装します。

例えば、DateOfBirth クラスを Date クラスを継承して実装したとします。この時、DateOfBirth クラスは、Date クラスの public / protected メソッドを受け継ぐので、Date クラスと同様の操作が可能です。Date クラスには、日付の加算、減算といったメソッドがありますが、このコンテキストの生年月日に関してはそういった操作は不要です。不要なだけでなく、うっかり使ってしまうと想定外の動作を招く場合もあります。

こうした違いは、IDE で開発すると明確です。委譲版 DateOfBirth は、age メソッドのみ補完候補となります。一方、継承版では、age メソッドに加えて、Date クラスのメソッドが多数出現します。一つしかボタンが無いのと、たくさんのボタンがあるのと、どちらが利用者として分かりやすいかは一目瞭然です。

委譲版 DateOfBirth

継承版 DateOfBirth

対象に特化する（汎用性を求めない）

上記、継承が使われる理由として、DRY を意識しすぎるため、継承で実装の再利用を行いたいというものがあります。

例えば、このシステムに配送日といったモデルがあったとしましょう。生年月日も配送日も日付を示すものなので、Date クラスを基底クラスとし、それぞれ継承したとします。しかし、生年月日と配送日を同種のものとして扱う場面というのは、現実世界ではあまり思い当たりません。

ドメインに特化したクラスの実装では、汎用的に実装する必要はなく、対象にのみフォーカスして実装します。

これは、一般的な汎用クラスとは指向している方向が異なります。あくまでドメインに特化したクラスなので、汎用性を考える必要はありません。*2

もし、実装を共有したいという目的であれば、共通処理を行う別クラスを実装して、そこに委譲するか、トレイトにまとめるという手法を取ると良いでしょう。

一つの概念を表す小さなクラスを作る

今回の生年月日のように、一つの概念のみを示すクラスを作るようにします。凝集度が高い小さなクラスを作ることで、実装しやすく、使いやすく、テストしやすいクラスになります。

こうしたクラスは取り回しが楽なので、どのようなアーキテクチャであっても、取り入れることができます。特に、DDD のようなドメインを意識したアーキテクチャでなくても、一部だけでも、一つの概念だけでも、簡単に取り込むことができます。

実際の開発では、ValueObject（値オブジェクト）として実装するところから始めると良いです。

コンテキストによって異なる

DDD でも「境界付けられたコンテキスト」があるように、コンテキストというのは重要な概念です。

同じ「生年月日」でも、本エントリで扱う「生年月日」と別のシステムで扱う「生年月日」では、あるべき振る舞いが異なるかもしれません。今回は年齢の算出のみを実装しましたが、「今日が誕生日かどうか」「今月が誕生月か」といった振る舞いが必要となる場合もあるでしょう。むしろ、この2つのみが関心事であれば、「年齢を算出する」は不要かもしれません。

このように、同じ用語、概念であっても、コンテキストによって求められるものは異なります。つまり、生年月日とはこうあるべきといった汎用の生年月日クラスを実装したとしても、それがそのまま適用できるかどうかは、コンテキストによって異なるということです。

ユースケース

こうしたドメインに特化したクラスを少しづつ導入したい場合は、ValueObject として導入するのが実装するのが良いでしょう。ValueObject にすれば、操作が限定できるだけでなく、オブジェクトの不変条件を内包したり、内部表現をカプセル化することができます。

例えば、下記のようなものが考えられます。

日付（日付ライブラリは高機能なわり、ドメインで要求されるものは一部。）
数値、特に演算が行われるもの（金額、ポイントなど。演算の限定、制約条件の付与。）
要求仕様が明確なデータ（商品コードなど。）

それ以外でも、サービスのように状態を保持しない処理もドメイン特化クラスで実装しやすい箇所です。

例えば、暗号処理なら、実際の暗号化や複合処理は別クラスで実装し、後はユースケース別のクラスからこれらのクラスを委譲で利用して、暗号化や複合を行うという場合に使えます。暗号処理は、暗号化と複合をペアで行う場合が多いので、ベアごとにクラスを分けると、ここで処理で暗号化したものは、あそこで複合しているというのが分かりやすくなります。

さいごに

こうしたドメインに特化したクラスを作るというのは、一見面倒なように見えますが、やってみると面白いものです。

生年月日も、汎用日付オブジェクトで表現すれば、それで終わりです。一方、生年月日クラスを実装すると、生年月日にどのような振る舞いが求められているかを考えることになります。このような視点で仕様を見ていけば、一つ一つの用語にも関心がいき、より深くドメインを理解して、コードに表現するようになります。

これは、教条的なものではなく、むしろ感覚に近いもので、こうしたプラクティスを重ねていくことで、身についていくもののように思います。

ドメインに必要な部品を少しづつ作っていき、それを組み合わせて構築していくという作業は、安心感もあり、とても楽しい作業です。身近なところから、取り組んでみてはどうでしょうか。

blog.shin1x1.com

*1:誤って押して、想定外の注文が飛ぶことはありますが

*2:ドメインコンテキスト内で汎用性を持たせるということは有り得ます。

「DDD パターンを活用した Laravel アプリケーション開発」を Laravel Osaka 2016 で発表しました。

2016-11-15T11:00:00+09:00

2016/10/19 に大阪で開催された Laravel Osaka 2016 にて、「DDD パターンを活用した Laravel アプリケーション開発」を発表しました。

会場の MOTEX さん。巨大スクリーンが 2 面あり、話しやすい環境でした。

発表資料

Laravel の具体的なテクニックに比べると抽象的な内容なので、どれだけ伝えられるか思案したのですが、聞いて頂いた方からのフィードバックや参加者アンケートでも概ね良い評価を頂けたので安心しました。

ValueObject については、さらに掘り下げて話せるテーマなので、これ単体でもまた話してみたいです。

Value Object は基本ですね |
DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel https://t.co/ZzRTnt0tY6
— 増田亨． (@masuda220) October 29, 2016

いつも blog や資料を参考にさせて頂いている増田さんに tweet して頂きました。インターネットっていいですね :)

質疑応答

発表の後の質疑応答では、多数の質問がありました。質問に対して的確な答えができたかは別にして、その場で今話した内容について意見交換ができるのは楽しいですね。

さらに、イベント終了後の懇親会や、後日、別の場でも発表についての質問や意見があり、そこから議論に発展することもありました。

話したことに対するリアクションが貰えるのは嬉しい限りで、発表者冥利に付きますね。

質問頂いた内容は、ざっと下記のようなものでした。（発表後の質疑応答以外のものも含む）

DDD をはじめるには、どこから手を付ければ良いか？
ValueObject を多数作った際のパフォーマンスについて
デメテルの法則について
なぜ、あえて Laravel を使っているのか？
リポジトリパターンと Eloquent について
遅延評価クエリをどう組み込むか
例外の使い方

今回の発表内容は、Laravel に関する内容は一部のみで、大筋はどういったフレームワーク、言語でも関連することなので、色々な人が自分なりの解釈で考えやすい題材であったのが一つ理由としてあるでしょう。

また、各技術の紹介や解説の発表に比べ、それらをどういった考え方で、いかに組み合わせるかというものは少ないように思います。

システム開発を行うならば、誰もが日々頭を捻りながら行っている行為なのですが、こういった話が勉強会などで表に出ることはあまり多くありません。

ドメインやコンテキストがそれぞれ異なるので、他人に話しにくいというのはありますが、今回のようにある程度抽象化すれば、みんなで考えられる題材になるので、もっと色々な人がこういった話をすると良いですね。（私はぜひ聞きたいです！）

さいごに

Laravel Osaka 2016 は、おそらく国内での Laravel 単体のイベントとしては最も大きい規模だったと思います。第 1 回目ということで、関西だけでなく、東京や福岡からスピーカーも参加者も集まっていて、どのセッションも興味深い内容でした。

スタッフのみなさん、楽しいイベントをありがとうございました！

「正規表現再入門」を PHP カンファレンス 2016 で発表してきました

2016-11-04T10:43:21+09:00

2016/11/03 に開催された PHP カンファレンス 2016 にて、「正規表現再入門」を発表してきました。

資料

speakerdeck.com

togetter.com

内容は、正規表現のマッチングの動き、量指定子のマッチングパターン、バックトラックやパフォーマンスへの影響についてです。

下記のエントリを下地にして、マッチングの動きを分かりやすく伝えることを意識してお話しました。 blog.shin1x1.com

参加された方からは、「分かりやすかった」といった好意的なフィードバックを頂けたので、発表して良かったです。

これから正規表現を学ぶにしても、マッチングがどのように行われるかをざっくりと知っておけば、正規表現を書く際にも動きが想像できるので、この発表がお役に立てると嬉しいです。

偶然、同じ時間帯に発表があった徳丸さんのセッションでも正規表現に触れられていたようで、Twitter の TL が微妙に交錯しているのが面白かったです :)

SQL と似た感覚

下地となったエントリでも書いたのですが、正規表現と SQL はやはり似ているなあと感じます。懇親会でも、発表を聞いて頂いた方との会話で話題になりました。

宣言的に書く言語は、記述しやすく理解しやすいのですが、どのように実行されるかはブラックボックスになります。もちろん、それは利点（How ではなく、What に集中できる）なので、実行エンジンが良しなにやってくれる時は全く持って問題ありません。

ただ、今回のバックトラック爆発のように仕組み上発生しうる挙動に関しては、利用側がそれを意識して書く必要があります。

特に、正規表現はバリデーションで外部から来た値をそのまま扱う場面でよく利用されるため、問題があればすぐに影響を受けることになります。

SQL を書く時にデータベースエンジンの動きをざっくりでも意識するように、正規表現でも意識すると良いですね。

さいごに

今年は、午後最後のセッションで、途中にサイン会などもあったので、t_wada さんのセッションだけ参加しました。

このセッションは素晴らしくて、同じように参加した人からも大絶賛でした。内容はもちろんのこと、構成や説明など伝え方がとても参考になりました。自分の発表にも取り入れられる要素があったので、今後に生かしていきたいです。

懇親会やその後の N 次会でも、色々な方とお話ができて、楽しい時間でした。毎年そうですが、蒲田の PHP カンファレンスは最高ですね！

運営のみなさん、今年も楽しいイベントをありがとうございました。

パフォーマンスを意識して正規表現を書く

2016-08-23T11:00:00+09:00

正規表現を書く際、どのようなパターンにマッチさせるか、どこをキャプチャするかという視点で記述することはあっても、パフォーマンスを考えて記述するというのはある程度知っている人でなければ忘れがちな視点です。

このエントリでは、バックトラックをメインに正規表現がパフォーマンスに及ぼす挙動について見ていきます。

対象の正規表現エンジン

ここでは、従来型 NFA を対象としています。具体的には、PHP の preg_ 関数で利用している PCRE や mb_ereg 関数が利用している鬼車です。Perl や Ruby、Python、Java、.NET でも従来型 NFA を採用しているので、似た挙動となるでしょう。

「従来型 NFA」や「バックトラック」などの用語については、「詳説正規表現第3版」のものを用いています。

バックトラックによるマッチ探査

正規表現エンジンでは、指定された文字列が、パターンにマッチするかどうかを判別する際、記述された正規表現で取り得るマッチパターンが見つかるように何度もマッチングを行います。

例えば、\d+\d という正規表現があり、これに 123 という文字列がマッチするか preg_match 関数でチェックします。

<?php
var_dump(preg_match('/\d+\d/', '123'));

これを実行すると、\d+ の部分は、文字列 123 にマッチします *1。しかし、次の \d にマッチする文字列が無いので、一つ前のパターン（\d+）に戻ります。次は、\d+ を 12 にマッチさせます。次の \d は、3 にマッチするので、これで全体のマッチが成功します。

下記では、この流れを示しています。()が \d+ に、{} が \d がマッチした箇所で、[]が現在マッチを試みている文字になります。

* (123)[]  <--- `\d+`はマッチするが、`\d`がマッチしないので、`\d+`へ戻る
* (12){3}  <--- `\d+`も`\d`もマッチする

正規表現は、前から順に適用されていくのですが、後続のパターンがマッチしない場合に一つ前のパターンに戻って、別のマッチ方法を試行するのをバックトラック（backtracking）と呼びます。バックトラックは、正規表現に限らず、正しい解を探るためのアルゴリズムです。詳細は、下記で。

https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%82%AF%E3%83%88%E3%83%A9%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0

「マッチしない」を確定させるのは遠い道程

次は、マッチが失敗するパターンとして、正規表現 \d+\d[^\d] を 123 という文字列にマッチさせます。

はじめに \d+ は文字列 123 にマッチします。次の \d にマッチしない（文字列が無い）ので、バックトラックが発生します。次は、\d+は文字列 12 に、\d は文字列 3 にマッチします。最後の [^\d] にマッチしない（文字列が無い）ので、バックトラックが発生します。今度は、\d+ を文字列 1 に、\d を文字列 2 にマッチさせますが、[^\d] と文字列 3 はマッチしません。

次は、文字列の先頭を 1 文字進めて 23 に対してのマッチを試みますが、こちらもマッチには成功しません。さらに、文字列 3 に対するマッチも失敗し、最終的には全てのパターンで失敗します。

下記では、この流れを示しています。()が \d+ に、{} が \d がマッチした箇所で、[]が現在マッチを試みている文字になります。

* (123)[]    <--- `\d+`はマッチするが、`\d`がマッチしないので、バックトラック
* (12){3}[]  <--- `\d+`と`\d`がマッチするが、`[^\d]`がマッチしないので、バックトラック
* (1){2}[3]  <--- `\d+`と`\d`がマッチするが、`[^\d]`がマッチしないので、バックトラック
* 1(23)[]    <--- 1文字進めてマッチング開始。`\d+`はマッチするが、`\d`がマッチしないので、バックトラック
* 1(2){3}[]  <--- `\d+`と`\d`がマッチするが、`[^\d]`がマッチしないので、バックトラック
* 12(3)[]    <--- 1文字進めてマッチング開始。`\d+`はマッチするが、`\d`がマッチしないので、バックトラック
* 123[]      <--- 1文字進めてマッチング開始。`\d+`がマッチせずに終了

このように、「マッチしない」と結論付けるために、指定した正規表現で取り得る全てのマッチングを行います。この挙動が場合によっては、パフォーマンスに大きな影響を及ぼします。

爆発するマッチング

マッチさせるまで（マッチしないことを確定させるため）、あらゆるマッチングを行うがゆえに正規表現や文字列によっては、マッチングの組み合わせパターンが膨大になる可能性があります。

マッチングが膨大になる様を確認するために、regex101.com というサイトを利用します。このサイトでは、正規表現と文字列を指定すると、正規表現エンジンがどのようにマッチングを行っていくかを表示してくれます。

regex101.com

例えば、上記の例（\d+\d[^\d]）であれば、下のような表示となります。これを見ると、文字列 123 に対して、14 steps がかかっていることが分かります。

ここで文字列を 123456789 という 9 文字に増やすと、91 steps となります。

マッチングが膨大になる場合を見るために、(\d*\d+)+\d[^\d] という正規表現を利用します。これは、前述の \d+\d[^\d] とマッチする文字列は同じです。このパターンを前述の 9 文字にマッチさせると、なんと 33,805 steps になりました！

https://regex101.com/r/eB0dM5/1

このようにわずか 9 文字の文字列に対するマッチングでも正規表現の書き方によって、マッチングの組み合わせが膨大に膨らむことが分かります。より複雑な正規表現や与えられる文字列が長い場合は、パフォーマンスへの影響が出てきます。

ReDosという攻撃

こうした正規表現エンジンの特性を利用した攻撃が ReDos です。ReDos については、下記の大垣さんのエントリが参考になります。

ReDoSの回避 | yohgaki's blog

特に量指定子（*、?、+、{n,m}）を入れ子にしたり、同じ文字クラスを重ねたりすると組み合わせパターンが多くなるので、こうした問題が起こる可能性があります。

末尾にあるスペースにマッチ

上記の ReDos とは別のパターンですが、単純な正規表現でも DoS を引き起こす場合があります。

stackoverflow.com では、文字列前後のスペースを除去する ^[\s\u200c]+|[\s\u200c]+$ という正規表現に対して 20,000 文字のスペースが含まれた文字列が送信されたために、上記のマッチングの組み合わせが膨大になり、34 分間アクセス不能になるという事態がありました。

Stack Exchange Network Status — Outage Postmortem - July 20, 2016

StackExchangeが攻撃されたReDoSの効果 | yohgaki's blog

大垣さんのサイトでも実証されていますが、Stack Overflow の事例を参考に文字列末尾にあるスペースを正規表現でマッチさせて取り除くという処理を見てみます。

まずは、正規表現を単純化して、\s+$ を利用し、文字列は a（半角スペース 3 文字）にマッチさせる場合で動きを見ます。

この場合、下記のようにマッチングを行なわれます。半角スペースが見えるように _ としています。人間が見れば、文字列の末尾が a なので、どのようにマッチングさせても成功しないのは明白なのですが、正規表現エンジンでは、前から順に愚直に評価していきます。

* (___)[a] <--- `\s+`はマッチするが、`$`がマッチしないのでバックトラック
* (__)[_]a <--- `\s+`はマッチするが、`$`がマッチしないのでバックトラック
* (_)[_]_a <--- `\s+`はマッチするが、`$`がマッチしないのでバックトラック
* _(__)[a] <--- 1文字進めてマッチング。`\s+`はマッチするが、`$`がマッチしないのでバックトラック
* _(_)[_]a <--- `\s+`はマッチするが、`$`がマッチしないのでバックトラック
* __(_)a <--- 1文字進めてマッチング。`\s+`はマッチするが、`$`がマッチしないのでバックトラック
* ___[a] <--- 1文字進めてマッチング。`\s+`がマッチしないのでバックトラック
* ___a[] <--- 1文字進めてマッチング。`\s+`がマッチせずに終了

スペースが 3 文字ではなく、20,000 文字となれば、それだけ多くのバックトラックが発生するため、処理に時間がかかるようになります。

パフォーマンスを計測するために下記のコードを実行してみました。それぞれのスペースの最後には a が付いているのでマッチングは失敗します。

<?php
function benchmark($title, callable $target) {
    echo '# ' . $title, PHP_EOL;
    $start = microtime(true);
    $target();
    echo microtime(true) - $start, PHP_EOL;
    echo PHP_EOL;
}

$strings = [];
foreach ([20, 200, 2000, 20000, 200000] as $no) {
    $string = str_repeat(' ', $no) . 'a';
    benchmark('preg_replace' . $no, function () use ($string) {
        return preg_replace('/\s+$/', '', $string);
    });
}

このコードを PHP 5.6 と 7.0 で実行した結果が以下です。2,000文字あたりから処理速度が低下していき、20,000文字、200,000文字で急激に処理時間がかかっています。なお、5.6 より 7.0 の方が文字数が多い場合は処理が速いので、何かしらの最適化が行われているのかもしれません。

PHP 5.6.24

文字長	実行時間
20文字	0.05ms
200文字	0.35ms
2,000文字	7.2ms
20,000文字	2,438ms
200,000文字	233,513ms

PHP 7.0.9

文字長	実行時間
20文字	0.4ms
200文字	0.2ms
2,000文字	5.8ms
20,000文字	498ms
200,000文字	50,352ms

正規表現を改良

文字列末尾のスペースにマッチングさせる正規表現を改善するために \s++$ に変えてみます。元の最大量指定子（\s+）を絶対最大量指定子（\s++）に変更しただけです。

これでベンチマークを取ると下記のようになりました。両バージョンとも処理速度が改善しており、200,000 文字で見ると、PHP 5.6 で 18 倍、PHP 7.0 で 4 倍と大きな改善となっています。変更後は、PHP 5.6 と PHP 7.0 でほぼ互角になっているのも興味深い点です。

このように正規表現の書き方一つで、大きくパフォーマンスが変わる場合があります。

PHP 5.6.24

文字長	実行時間
20文字	0.17ms
200文字	0.041ms
2,000文字	1.91ms
20,000文字	172ms
200,000文字	12,879ms

PHP 7.0.9

文字長	実行時間
20文字	0.26ms
200文字	0.047ms
2,000文字	1.29ms
20,000文字	123ms
200,000文字	12,544ms

絶対最大量指定子を使った場合（ aへのマッチング）は、下記のようなマッチングを行います。絶対最大量指定子は、貪欲なマッチングとなり、かつマッチした文字列をアトミックに扱います。これにより、バックトラックの発生が抑えられるのでマッチング回数を抑制できます。これは、アトミックグループ（(?>)）でも同様の効果が得られます。

* (___)[a] <--- `\s++`はマッチするが、`$`がマッチしないのでバックトラック
* _(__)[a] <--- 1文字進めてマッチング。`\s++`はマッチするが、`$`がマッチしないのでバックトラック
* __(_)a   <--- 1文字進めてマッチング。`\s++`はマッチするが、`$`がマッチしないのでバックトラック
* ___[a]   <--- 1文字進めてマッチング。`\s++`がマッチしないのでバックトラック
* ___a[]   <--- 1文字進めてマッチング。`\s++`がマッチせずに終了

今回計測したPHPコードは、下記です。

regex_trim.php · GitHub

あえて正規表現を避ける

PHP でこの処理を単純に考えれば、ltrim関数で簡単に実装できます。

ltrim関数を使うと、200,000文字のスペース + a の場合でも、わずか 1ms 以下でした。

stackoverflow.com では、正規表現を使うことをやめ、文字列処理（substring関数）に取り替えたようです。

さいごに

正規表現の書き方や文字列が、パフォーマンスに影響を与えることを見てきました。

マッチングパターンのみに注力して記述した正規表現が、正規表現エンジンによって、上手い具合にチューニングされて動作すれば良いのですが、最適化が上手く働かないケースでは、その挙動を把握した対処を行わないとパフォーマンスの問題を抱えることになります。

このあたりは、SQL にも似たものを感じしますね。

正規表現は、Web アプリケーションにおいてはバリデーションで利用されることが多く、外部の値をいきなり正規表現にかけてチェックするということもあります。バリデーションは成功しないが、DoS となるような値を投げられて、パフォーマンスが低下したり、サービスが停止させられる場合も考えられます。

正規表現のパターンを考慮する、文字列長をチェックしておく、場合によっては正規表現を使わない、など対処法は考えられるが、まずは正規表現がパフォーマンス上の問題になりうるということを認識することが第一歩になるでしょう。

参考

正規表現エンジンの挙動については、下記の 2 冊がとても参考になります。どちらかというと、「詳説正規表現」は正規表現を利用する側、「正規表現技術入門」は正規表現エンジンを実装する側から正規表現を見た本となっています。どちらも内部の動きを分かりやすく解説しているので、本エントリのような内容をより知りたい方には特におすすめです。

どちらも Kindle 版が無いので、電子版を購入する場合は、オライリー社サイト、技術評論社サイトで購入します。

詳説正規表現第3版

作者: Jeffrey E.F. Friedl,株式会社ロングテール,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2008/04/26
メディア: 大型本
購入: 24人クリック: 754回
この商品を含むブログ (85件) を見る

作者: 新屋良磨,鈴木勇介,高田謙
出版社/メーカー: 技術評論社
発売日: 2015/04/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

*1:これは、PCRE の量指定子が最大量指定子なためです。最小量指定子や絶対最大指定子を指定したり、正規表現エンジンタイプが異なればマッチの仕方は変わります。

より実践的なDDD本「.NETのエンタープライズアプリケーションアーキテクチャ第2版」

2016-07-26T11:00:00+09:00

DDD 関連の書籍といえば、Eric Evans の DDD 本（エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) ）や、Vaughn Vernon の IDDD 本（実践ドメイン駆動設計 (Object Oriented SELECTION) ）が有名です。

DDDで登場する実装パターンや周辺知識をより実践的に解説しているのが、「．ＮＥＴのエンタープライズアプリケーションアーキテクチャ　第２版 (マイクロソフト公式解説書)」（naa4e）です。

.NET 以外にも大いに通じる内容

本書は、.NET の名を冠しており、サンプルコードは、C# で記述されています。また、利用するライブラリも .NET 周辺のものであったり、解説で登場する RDBMS も、Web 系でよく登場する MySQL や PostgreSQL よりも、SQL Server や Oracle がメインとなっています。

しかし、.NET 固有の話はそれだけです。.NET 固有の内容は、枝葉の部分であり、メインの内容は、プラットフォームやプログラミング言語に関わらずとても参考になるものでした。

日頃、.NET 界隈にいない人間としては、正直、マイクロソフト公式解説書としての体裁になっているがゆえに避けてしまう人がいるのが、勿体無いとさえ感じる本でした。

DDDをガラスケースから日々実践するプラクティスへ

DDD 本、IDDD 本と本書を比べると、より実践に寄せた内容となっており、DDD をより身近な普段の開発に適用するために解説されています。

実際の開発では、上手くパターンにあてはめられなかったり、妥協してしまう場面もあるのですが、そのあたりも考慮に入れられています（トランザクションスクリプトも場面によっては有用なパターンである、など）。本書の表現を借りると、ヒーローがいなくても、一般の開発者が DDD 取り組む方法を示した本とも言えます。

それぞれ執筆された時期が異なる（DDD 本（2003年）、IDDD 本（2013年）、本書（2014年））ので、理論から実践、さらに実践した上で現実的な落し込みといった具合に、より現実的な内容に推移しているのが興味深いです。

私は、DDD 本、IDDD 本、本書の順序で読んだのですが、本書が一番理解しやすいと感じました。*1

本書の内容

本書の目次は下記です。

現代の設計手法や開発手法、OOPの基礎（SOLID原則など）やテスト手法からはじまり、DDDで利用されるパターンの解説に入っていきます。

本書で興味深いのは、第6章のプレゼンテーション層がドメインアーキテクチャのすぐ後に来ている点と、CQRS とイベントソーシング（ES）に多くのページが割かれている点です。

■第1部 基礎
第1章 現代のアーキテクトとアーキテクチャ
第2章 成功のための設計
第3章 ソフトウェアの設計原則
第4章 高品質なソフトウェアの作成

■第2部 アーキテクチャの考案
第5章 ドメインアーキテクチャの発見
第6章 プレゼンテーション層
第7章 伝説のビジネス層

■第3部 サポートアーキテクチャ
第8章 ドメインモデルの紹介
第9章 ドメインモデルの実装
第10章 CQRS の紹介
第11章 CQRS の実装
第12章 イベントソーシングの紹介
第13章 イベントソーシングの実装

■第4部 インフラストラクチャ
第14章 永続化レイヤー

ユーザエクスペリエンス(UX)ファースト

ソフトウェアの世界では、バックエンドから取り組むのが慣例となっていました。私たちの多くは、プレゼンテーションをシステムのそれほど高尚な部分だと見ておらず、ビジネス層をデータアクセス層が完成してから取り組めばよい、という程度に考えていました。しかし、システムの複雑さを問わず、プレゼンテーションとバックエンドが等しく必要であることに疑問の余地はありません。

Webアプリケーションでもサーバサイドをメインにやっていると、プレゼンテーションの重要性は認識はしていても、重点をサーバ側に置いてしまいがちでした。

しかし、プレゼンテーションはユーザが直接システムに触れるインタフェースであり、ここからシステムのユースケースやタスクを見ていくというのは当然のことです。

自分が設計する際は、プレゼンテーションももちろん考えますが、どちらかと言えば、サーバサイドの設計を主に考えていた節があるので、ハッとさせられました。

CQRS を身近なパターンに

CQRSは、ソフトウェアアーキテクチャにおけるコロンブスの卵です ── すなわち、自明ではない問題に対する驚くほど明確でそつのないソリューションです。開発者とアーキテクトは、DDDとDomain Modelの階層化アーキテクチャを理解し、正当化し、機械化することに何年も費やしてきました。特に複雑なビジネスドメインでは、クエリスタックとコマンドスタックの両方をドメインモデルで実現することがきわめて難しいという問題と格闘してきました。 CQRSにより、すべてが一夜にして変わってしまい、複雑なビジネスドメインがはるかに管理しやすくなりました。

IDDD 本では、やや特殊なパターンとして解説されていた CQRS が、多くの場合に適用できる身近なパターンとして解説されています。

このあたりは、私もドメインモデルからクエリを分離して、クエリについては、DTOを返すリポジトリを作って実装した経験から、わりと使い勝手が良いパターンではないかという印象を持っていました。

本文では、単なる CRUD パターンでも、CQRS にしてコマンドとクエリの関心事を分けるのは意味があると書かれており、CQRS に興味がある人には参考になる内容でしょう。

イベントソーシング（ES）と似たものは、30年以上前からある

先に挙げたアプリケーションはどれも数十年前から存在しているもので、COBOLやVisual Basic 6でかかれたものさえあります。つまり、イベントソーシングなんて仰々しい名前が付いていても、決してソフトウェアの新しい概念の到来を告げるものではないのです。

新たな名前が付いたものが出てくると、身構えてしまいますが、実は従来からあるものに名前が付いてパターン化したものというのも良くあります。

その最たるものが、GoF でお馴染みのデザインパターンでしょう。イベントソーシングもこうした以前からあるものをパターン化したものです。

現実世界での出来事では、発生した事象が消えてなくなることはなく*2、事象をイベントとして残していくというのは特にユーザからすると理解しやすいものです。

例えば、商品購入を記録する場合、購入情報のドメインモデルを保存し、ステータスが変わる度にそれを書き換えます。そして、イベントを補足情報としてログに記録するというのは良くあるパターンです。

イベントソーシングでは、これを逆転し、イベントを記録する方を主とします。そして、保存したドメインモデルは、あくまでもスナップショットとして扱います。イベントには、必要な情報が全て記録されているので、原理的にはそれらを順に適用していけば、どの時点のドメインモデルでも再現できるからです。

実際にイベントソーシングを実装するとなると、パフォーマンスの問題は無視できないのですが、ここについても実装のアイデアが解説されています。

さいごに

DDD 本を読んで、自分たちが取り組んでいるプロジェクトに DDD を実践してみたい人や、実際に取り組んでみたもののまだしっくり来ない人に手にとって見てもらいたい本です。

ユーモアを交えて、平易な表現で書かれており、理解しやすいので、これから DDD を学ぶ人や OOP の基礎を見直す人にも良さそうです。

実装で具体的なイメージを持った状態で、理論に立ち返るとより理解が深まるので、この本から DDD 本や IDDD 本に戻るのも良いですね。

なお、この本を読んだ後に、Amazon でリコメンドされた「C#実践開発手法 (マイクロソフト公式解説書)」も気になる内容だったので、こちらも読んでみたいと思います。

.NETのエンタープライズアプリケーションアーキテクチャ第2版　.NETを例にしたアプリケーション設計原則

作者: ディノエスポシト,アンドレアサルタレロ
出版社/メーカー: 日経BP社
発売日: 2015/06/18
メディア: Kindle版
この商品を含むブログを見る

エリック・エヴァンスのドメイン駆動設計

作者: Eric Evans
出版社/メーカー: 翔泳社
発売日: 2013/11/20
メディア: Kindle版
この商品を含むブログ (4件) を見る

実践ドメイン駆動設計 (Object Oriented SELECTION)

作者: ヴァーン・ヴァーノン,高木正弘
出版社/メーカー: 翔泳社
発売日: 2015/03/17
メディア: 大型本
この商品を含むブログ (4件) を見る

*1:もちろん、それは前 2 冊を読んで、多少なりとも実践したからこそというのはあります。

*2:購入商品をキャンセルしても、購入した事実は消えない

Shin x Blog

誰のためのソースコード?

ソースコードとメンタルモデル

ソースコードの概念モデル

実行モデル

プログラマモデル

ユーザモデル

誰のためのソースコード?

さいごに

メモ

「Kubernetes で構築する PHP 開発環境」を発表しました

発表資料

Kubernetes on CircleCI による CI

対話

さいごに

「独立したコアレイヤパターンの適用 - fortee 編 -」を発表しました

発表資料

100 人でやるモブプロ

PhpStorm

独立したコアレイヤパターン

さいごに

関数型言語で DDD - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

概要

構成

ドメインを理解し、モデリングする

端的なフレーズ

Database-Drive-Design や Class-Driven-Design との違い

型、型、型

関数型言語による実用例

恐怖のモナド

さいごに

参考

Laravel におけるリポジトリ実装のポイント

1. ドメインデータの入出力にリポジトリパターンを使う

2. メソッドの型宣言にドメインデータを指定する

3. 機械的に CRUD メソッドを実装しない

4. Eloquent を利用したリポジトリクラスの実装

5. 複数テーブルを扱うリポジトリ

6. Paginator との連携

さいごに

rerun - コマンドが終了したら自動で再実行するツールを作りました

動作イメージ

動機

rerun

インストール

さいごに

yae - YAML alias を展開して出力するツールを作りました

YAML anchor/alias

yae

インストール

利用方法

元の YAML との比較

「フレームワークとの付き合い方」を発表しました / Laravel JP Conference

発表資料

グラレコ

Ask the speaker

さいごに

「明日から使えるアーキテクチャ 独立したコアレイヤパターン」を発表しました / PHP カンファレンス仙台 2019

発表資料

スーパーヒーローがいなくても使えるパターン

質疑応答

さいごに

Vue.js + Vuex + TypeScript ファーストインプレッション

前提

これまで利用した構成

Vue.js 構成

雑感

ちょっと試す、がすぐにできる

vue-cli が楽

vue ファイル

template ディレクティブ

scoped css

vue-router / Vuex 連携

Vuex

mutation を直接呼んで、state を変更

コンポーネントから直接 state を操作

TypeScript

Vue.js 入門

さいごに

「PHPフレームワーク Laravel Webアプリケーション開発」を執筆しました

「明日から使えるアーキテクチャ独立したコアレイヤパターン」を発表しました / PHP カンファレンス仙台 2019