【PHP実践】Features¶

PHPにおける「Features」の概念とその実装戦略

現代のPHP開発において、「Features」という用語は、単なる機能追加を指す言葉を超え、アプリケーションの設計思想そのものを表す重要な概念となっています。特に、モノリスからマイクロサービスへの移行、あるいは「モジュラーモノリス」の採用が推奨される昨今、コードベースをどのように分割し、管理するかという課題に対する答えが、この「Feature」という単位に集約されています。

本記事では、PHPにおけるFeaturesの定義、ドメイン駆動設計（DDD）における位置付け、そして保守性を劇的に向上させるためのディレクトリ構成と実装パターンについて、実務的な観点から深く掘り下げます。

Featuresとは何か：コンテキストの境界を定義する

ソフトウェア開発における「Feature」とは、システムが提供する特定のビジネス価値や、エンドユーザーにとって意味のある一連の操作単位を指します。例えば、ECサイトであれば「ユーザー登録」「商品検索」「カート追加」「注文確定」などがそれぞれ一つのFeature（機能単位）となります。

従来のPHP開発（特にMVCモデルを単純に適用した場合）では、コントローラー、モデル、ビューといった「技術的な役割」ごとにディレクトリを分ける傾向がありました。しかし、プロジェクトが巨大化すると、一つの機能を追加・修正するために、コントローラー、サービス、リポジトリ、DTOなど、異なるディレクトリを行き来しなければならず、開発効率が低下します。

一方で、Featureベースの設計では、関連するすべてのクラスを「Features」という名前空間やディレクトリ配下に集約します。これにより、特定の機能に関わるコードが物理的に近接し、修正時の影響範囲の特定や、コードの可読性が飛躍的に向上します。

ディレクトリ構造による責務の分離

実務において推奨される構成は、機能単位でディレクトリを切り、その内部で技術的な責務を整理する手法です。以下に、モダンなPHPフレームワーク（LaravelやSymfony）を想定したディレクトリ構成の例を示します。


src/
  Features/
    Order/
      PlaceOrder/
        PlaceOrderController.php
        PlaceOrderRequest.php
        PlaceOrderService.php
        PlaceOrderResponse.php
      CancelOrder/
        ...
    User/
      Register/
        ...

この構造では、`Order`というドメインの中に`PlaceOrder`（注文確定）というFeatureが定義されています。このディレクトリ内には、その機能を実現するために必要なすべての要素が揃っています。これにより、新しいエンジニアが「注文機能」を修正する場合、`src/Features/Order/PlaceOrder/`を見るだけで完結するため、認知負荷が大幅に軽減されます。

実装パターン：コマンド・クエリ責務分離（CQRS）の導入

Featuresを実装する際、最も相性が良いのがCQRS（Command Query Responsibility Segregation）の考え方です。特に、書き込み系の「Command」と読み取り系の「Query」を意識的に分けることで、Featureの複雑性を制御できます。

以下の例は、サービス層を単一の「Actionクラス」として実装するパターンです。


namespace App\Features\Order\PlaceOrder;

use App\Domain\Order\OrderRepository;
use App\Domain\Order\OrderFactory;

class PlaceOrderAction
{
    private OrderRepository $repository;
    private OrderFactory $factory;

    public function __construct(OrderRepository $repository, OrderFactory $factory)
    {
        $this->repository = $repository;
        $this->factory = $factory;
    }

    public function execute(PlaceOrderRequest $request): PlaceOrderResponse
    {
        // ビジネスロジックの実行
        $order = $this->factory->create($request->all());
        $this->repository->save($order);

        return new PlaceOrderResponse($order->getId());
    }
}

このように、一つのFeatureに対して一つのActionクラスを割り当てることで、メソッドの肥大化を防ぎ、単一責任の原則（SRP）を遵守しやすくなります。コントローラーはあくまで入力を受け取り、Actionを呼び出し、レスポンスを返すという「橋渡し」の役割に徹することが可能になります。

依存関係の管理とカプセル化

Feature単位でコードを分割する際の最大の懸念は「Feature間の密結合」です。例えば、`Order`機能が`User`機能の内部クラスに直接依存してしまうと、結果として全体が巨大な結合体となってしまいます。

これを防ぐためには、以下の原則を守ることが重要です。

1. インターフェースの活用：他のFeatureを参照する場合は、具象クラスではなくインターフェースを介する。
2. パブリックAPIの定義：各Featureには「外部から呼び出しても良いクラス（Public API）」を明確にし、それ以外は`private`や`protected`、あるいは名前空間の制御でアクセスを制限する。
3. イベント駆動の採用：あるFeatureが他のFeatureに影響を与える場合（例：注文確定後に在庫を減らす）、直接サービスを呼び出すのではなく、イベントを発行して非同期的に処理を行う。

PHP 8.2以降で導入された`readonly`クラスや`enum`を積極的に利用することで、不変性を保証し、予期せぬ副作用を排除する設計が可能です。

実務アドバイス：既存のモノリスから移行するためのステップ

既存の巨大なプロジェクトをいきなりFeatureベースに変更するのはリスクが伴います。以下の段階的なアプローチを推奨します。

1. 新機能から始める：既存コードを修正するのではなく、新しく追加する機能から「Features」ディレクトリ配下に実装を開始してください。
2. 境界コンテキストの特定：既存のコードを整理する際は、ドメイン駆動設計における「境界コンテキスト」を意識し、論理的に独立している部分から少しずつ移動させます。
3. 共有コードの分離：複数のFeatureで使われるコードは、`src/Domain`や`src/Shared`といった共通ディレクトリに追い出します。ただし、ここにはビジネスロジックを含めすぎないよう注意が必要です。
4. テストの充実：Feature単位での分割は、テストのしやすさを向上させます。各ディレクトリに`Tests/`を配置し、ユニットテストを完結させることで、リファクタリングの安全性を担保してください。

まとめ

PHPにおける「Features」による設計は、単なるディレクトリ構成のルールではありません。それは、開発チームがビジネスの成長に合わせてコードベースを拡張し、複雑性を管理し続けるための「戦略的アプローチ」です。

技術的な役割（ControllerやService）による分類から、ビジネス上の価値（Feature）による分類へとシフトすることで、コードの可読性、保守性、そしてエンジニアの生産性は劇的に向上します。特に、大規模なPHPアプリケーションを運用するチームにおいては、この設計思想を早期に導入することが、長期的な技術的負債の蓄積を防ぐための最も効果的な手段と言えるでしょう。

もちろん、すべての小規模プロジェクトに過剰な抽象化を適用する必要はありません。しかし、将来的な拡張を見越した「Feature」という単位での思考は、熟練したエンジニアにとって必須のスキルです。本記事で紹介した構成と原則を、ぜひ次回の開発プロジェクトから実践してみてください。クリーンでメンテナンス性の高いPHPコードは、正しい設計思想の上にのみ成り立ちます。

スポンサーリンク
" "
タイトルとURLをコピーしました