Vertical Slice Architectureとは？機能単位にシステムを縦割りする設計アプローチ

Vertical Slice Architectureとは何か

Vertical Slice Architectureとは？機能単位にシステムを縦割りする設計アプローチ

Vertical Slice Architecture（垂直スライスアーキテクチャ）は、従来の層別アーキテクチャとは異なり、機能単位でシステムを縦方向に分割する設計手法です。各スライス（機能）はフロントエンドからバックエンドまで全ての処理を含み、UI、ビジネスロジック、データアクセスなどを自己完結的にまとめます。例えば、ユーザ登録機能であれば、その画面表示からユーザ生成、DB書き込みまでの処理がひとつのパッケージに集約され、他機能のコードとは独立して管理されます。こうした構造により、アプリケーション全体を「機能ごとのモジュール群」として扱えるため、変更の影響範囲が局所化され、保守性や開発効率が向上します。

提唱者と起源: Jimmy BogardがもたらしたVertical Sliceアーキテクチャ誕生の背景

Vertical Slice Architectureの提唱者はソフトウェア開発者のJimmy Bogard氏です。彼は2018年にこの概念を提示し、従来のオニオンアーキテクチャやクリーンアーキテクチャでの開発における煩雑さを解決するために考案しました。Bogard氏は「従来のレイヤード構造では機能追加時に複数のレイヤーをまたぐ変更が必要になり、抽象化や依存性管理が過度になる」と指摘。そこで彼は各機能（＝機能単位のリクエスト）を独立したスライスとして扱う方式を採用し、結果としてCQRS（コマンドとクエリの分離）パターンが自動的に得られると述べています。このようにBogard氏はVertical Sliceを「レイヤー横断ではなく機能に沿ったアーキテクチャ」として定義し、不要な抽象化を排して単純かつ局所的な変更を可能にするアプローチとして普及させました。

垂直スライスの基本要素: リクエストからUI、ビジネスロジック、データアクセスまでを包含する構造

Vertical Sliceでは、機能を実現するために必要な全要素を一かたまりの中に配置します。実際の実装では、機能ごとにフォルダ（または名前空間）を作り、その中にコントローラやハンドラ、ドメインロジック、リポジトリなどをまとめて配置します。これにより、各スライスは独立したミニアプリケーションのように振る舞い、ある機能の変更はそのスライス内だけに収まります。たとえば「注文管理」機能なら、OrdersControllerやOrdersHandlerが注文処理を行い、OrderドメインモデルやOrderRepositoryが注文データを扱う、といった具合に一機能で完結した構造となります。こうして1つの機能のコード変更だけに注力できるため、複数レイヤーを跨いで依存調整をする必要がなくなり、保守性とテスト容易性が向上します。

典型的なリクエスト処理の流れ: 垂直スライスによる機能単位の処理パイプライン

Vertical Sliceでは、APIリクエストや画面操作のたびに該当機能のスライス内で処理が完結します。具体的には、クライアントからのリクエストはまずその機能専用のコントローラやハンドラで受け取られ、その内部でドメインサービスやリポジトリが呼び出されます。この一連のパイプラインはすべて同一機能内で完結し、他の機能やレイヤーに依存しません。例えば、商品の在庫更新リクエストではProductsUpdateHandlerが実行され、そのハンドラ内でProductモデルやProductRepositoryが呼び出されることで処理が完了します。このように、リクエストから応答までが1つのスライス内で処理されるため、機能開発時にはその機能に必要なコードだけに集中でき、並行開発時の機能間干渉も減少します。

垂直スライスの概念図解: レイヤードではなく機能単位で切り出す全体構造

概念的には、垂直スライスは従来の水平なレイヤー分割ではなく、図のようにアプリを機能毎の縦断的なスライスに分割します。各スライスはUI、ドメイン、DBを縦に貫通し、アプリケーション全体はこれらの縦スライスが並ぶ形となります。これにより「機能ごとの独立性」が視覚化され、たとえばブログアプリでは投稿機能やコメント機能などが別々のスライスとして並行して存在するイメージです。こうした構造は、各スライスが他のスライスと独立して開発・テストできることを直感的に示しており、開発の自由度と拡張性を高める効果があります。

概要と仕組み

垂直スライスアーキテクチャの全体像: 機能単位で構成されたシステム構造

垂直スライスアーキテクチャでは、システム全体を機能単位のモジュール（スライス）で構成します。つまり、アプリケーションは「スライスの集合体」として捉えられ、各スライスは機能完結型のサブアプリのように振る舞います。この結果、各スライスは相互に干渉せずに独立して動作でき、必要な機能追加・修正もそのスライス内で完結します。Vertical Sliceはまたアジャイル開発との相性が良く、機能ごとに完結した形でリリース・テストが可能なため、開発スピードと品質の両立を実現します。

機能ごとの独立性: スライス間で依存しないモジュール構成と利点

各スライスは独立したモジュールとして設計されるため、スライス間の依存を極力排除します。具体的には、スライス間で共有するコード（共通ライブラリなど）は最小限に留め、機能固有の処理は必ず自スライス内に収めます。たとえば、注文機能のスライスが在庫機能の内部ロジックに依存することは避け、必要であればイベントやAPI経由で連携します。こうすることで、ある機能の変更が他機能に予期せぬ影響を与えず、モジュール性と保守性が向上します。

リクエスト毎の処理例: コントローラからデータ層まで完結する処理フロー

具体的な処理フローの例として、Web APIリクエストを考えます。垂直スライスの場合、ルーティング設定は機能ごとに存在し、例えば「/api/orders」へのリクエストはOrdersControllerに紐づきます。このコントローラはOrdersHandlerを呼び出し、そこからOrderドメインモデルやOrderRepositoryが実行されてDBへの更新まで行います。ポイントは、この一連の流れがOrders機能のスライス内で完結していることです。他の機能（例えば商品機能）の処理経路やレイヤーには依存せず、スライス外との結合は極力カプセル化されます。結果として、各リクエストは必要最小限のコードだけを経由するため、効率的な処理が可能になります。

フォルダ構造のサンプル: ソースコードを機能別に分割する方法

実装例としては、機能別にコードを配置するディレクトリ構成があります。たとえば大分類の「UseCase」や「Features」フォルダを用意し、その中に各機能（例：Order/Index、Order/Create など）ごとのサブフォルダを作ります。各サブフォルダには、その機能に必要なコントローラ、DTO、ドメイン、リポジトリ、サービスをまとめます。こうして機能ごとにディレクトリが完結するため、該当機能のコードのみを辿れば全体像が把握でき、レビューやテストも容易です。この構成は、フィーチャーフォルダパターンとも呼ばれ、垂直スライスの実装例としてよく用いられます。

横断的関心事の扱い: 認証・ログなど共通機能の組み込み方法

Vertical Sliceでも認証やロギング、例外処理といった横断的関心事（cross-cutting concerns）は必要です。一般的には、これら共通処理はミドルウェアやフィルタなどアプリケーション全体で適用される仕組みで実装します。垂直スライス化しても、認証チェックやロギングなどはこれまで通りグローバルに設定可能であり、機能スライスごとに個別に実装し直す必要はありません。つまり共通機能はシステム全体で扱いながら、ビジネスロジック部分だけをスライス内に閉じ込めることで、機能単位の独立性を損なわずに横断処理を実現できます。

利用する理由

Vertical Sliceを採用するメリット1: 開発効率と可読性の向上

Vertical Sliceアーキテクチャを採用すると、機能単位の独立によって開発効率が向上します。すべての処理が機能内に含まれるため、ある機能の変更が他機能に影響を与える心配が少なく、追加機能や修正を部分的に行えます。またコードが整理されてフォルダ構成も分かりやすいため、機能ごとの関連クラスを追いやすくなり、可読性やメンテナンス性も改善します。このようにVertical Sliceは複数のレイヤーをまたいだ処理を避け、開発者が「今自分が触っている機能だけ」を意識して作業できる点が大きなメリットです。

Vertical Sliceを採用するメリット2: テスト容易性とデプロイ効率の向上

各機能が自己完結的に設計されているため、単体テストや自動テストの粒度を機能ごとに設定できます。特定機能のロジックを検証するテストケースが他機能の影響を受けず、テストケースの作成や実行がシンプルになります。さらに、CI/CDパイプラインでは機能スライス単位でのデプロイが可能です。あるスライスに関する変更だけを新しいバージョンとしてリリースできるため、リリースの粒度を細かくして頻繁に展開できます。結果として、本番環境に対するリスクを抑えつつ、機能追加や修正を迅速に反映しやすくなります。

Vertical Sliceを採用するメリット3: アジャイル開発との親和性

Vertical Sliceはアジャイル開発手法と非常に相性が良い点もメリットです。機能を単位とするため、スプリントやイテレーションごとに「完成した機能」を確実にリリースできます。たとえば、ECサイトの「商品登録」「在庫更新」「注文照会」など、各機能を独立してスプリント内で完結させられます。チームが機能に集中して取り組めるため、タスク間の干渉が減り、作業効率が向上します。また機能ごとに責任者を分担できるため、チーム体制がスケールしやすく、組織内のコミュニケーションや作業分担が明確になります。

Vertical Sliceを採用するデメリット1: 重複コードと管理負荷

Vertical Sliceでは独立性を重視するあまり、異なる機能で共通して使われる処理がスライスごとに実装されるケースがあります。たとえば、複数機能で似たようなDTOやエンティティ、サービスロジックが必要な場合、各スライスで同様のコードを書く必要があり、変更時の一貫性維持が難しくなることがあります。また、共通部分を適切に抽象化しないと、機能修正のたびに複数箇所の更新が必要になり、かえって作業量が増えることもあります。つまりVertical Sliceはコードの複製リスクを伴うため、設計時に共通化のラインを見極める工夫が必要です。

Vertical Sliceを採用するデメリット2: 学習コストと適用判断の難しさ

新たなアーキテクチャ手法として、Vertical Sliceには独自の設計感覚が要求されます。特に小さなチームや初心者の場合、通常のレイヤード開発に慣れていると違和感が大きく、学習コストがかかります。加えて「どの規模やフェーズでVertical Sliceが有効か」を見極める判断も難しいケースがあります。大規模で厳密なバウンデッドコンテキストの分離が求められる場合は他方式（クリーンアーキテクチャやマイクロサービス）が適することもあり、プロジェクト要件に対する綿密な評価が必要です。Bogard氏自身も「リファクタリングやドメイン知識への深い理解がないチームには難しい」と述べており、適用にはチームのスキルセットやプロジェクト特性を考慮する必要があります。

総合評価: Vertical Sliceが向いている組織とプロジェクト

Vertical Sliceは、変化が激しく機能追加が頻繁に行われるアジャイル開発環境に向いています。具体的には、多数の機能が独立して進化するECサイトや業務系システムなどで有効です。また、将来的にマイクロサービス化を視野に入れている場合、機能毎の分割はその移行準備にも適しています。ただし、すべてのプロジェクトに最適というわけではなく、規模やビジネス要件に応じた判断が必要です。チームに設計原則とリファクタリングの経験があることが前提となるため、小規模・短命プロジェクトや開発経験の浅いチームには過剰になる可能性があります。

設計原則

原則1: 不要な抽象化を排するシンプルさの追求

設計段階ではシンプルさを最優先します。不要なレイヤーやインターフェイスは導入せず、当初はトランザクションスクリプトのような直線的な処理でも問題ありません。Bogard氏も「まずは簡単な実装から始め、実際にコードに匂いが出てきたら必要なパターンを適用する」と述べています。このアプローチにより、過剰な一般化や抽象化を避け、本当に必要な構造だけを追加できます。

原則2: 機能スライスごとの単一責任と関心の集中

Vertical Sliceでは「1つのスライス＝1つの機能」という単一責任の原則を徹底します。各スライスは特定の機能にフォーカスし、他の機能のロジックやデータアクセスを含めない設計とします。これにより、コードの見通しが良くなり、そのスライスを扱う開発者は機能の全体像に集中できます。関心の分離が明確になることで、バグの発見や機能追加の際に不要な影響範囲を避けることが可能です。

原則3: スライス間の依存関係を最小化する設計

スライス間の依存関係は極力なくします。各スライスは自己完結することを目標とし、他スライスからの直接参照や共有コード使用を最小化します。依存が必要な場合はAPIやイベントなど明示的な手段に限定し、インターフェイスを通じて疎結合にします。これにより、あるスライスの変更が他に影響を及ぼすリスクを低減し、システム全体の安定性が保たれます。

原則4: 段階的改善: 単純な構造から必要に応じたリファクタリング

Vertical Sliceでは、最初から完璧な設計を目指すのではなく、まずシンプルに始めて必要に応じてリファクタリングする姿勢を重視します。要件の変化やコード上の「におい」に応じてクラスやインターフェイスを追加していくことで、過度の設計を避けつつコード品質を高められます。この漸進的改善のアプローチにより、初期段階での設計コストを抑えながら、仕様変更に柔軟に対応できます。

原則5: ドメイン志向: ビジネスロジックを中心に構造化する考え方

ドメイン駆動設計（DDD）の観点では、Vertical Sliceはビジネス機能を中心に据える設計です。各スライス内ではドメインモデルやドメインサービスが中心的役割を担い、アプリケーション層やインフラ層はそれをサポートする形で構成します。このため、システム全体のビジネス要件を反映したモジュール分割が可能になり、要求変更がドメインロジックに直結する構造になります。ドメイン知識が各スライス内に閉じ込められることで、各機能の重要なビジネスルールを明確に表現できます。

実装例（.NET / Laravelなど）

.NETでの実装例: ContosoデモとVertical Sliceテンプレートの紹介

.NETの世界ではJimmy Bogard氏自らがContoso UniversityアプリでVertical Sliceパターンの実装例を公開しています。このサンプルではASP.NET Core上でMediatRを用い、機能ごとにコマンドやクエリハンドラを定義しています。また、.NET 8向けにVertical Slice用テンプレートがGitHubで公開されており（例: Hona氏のリポジトリなど）、これらを利用して簡単に垂直スライス構造のプロジェクトを作成可能です。実際の実装では、各機能に対してController/Handler/Repositoryクラスをまとめ、MediatRのパイプラインで機能単位の処理を呼び出す手法が一般的です。

Laravelでの採用例: UseCaseフォルダによる機能分割実践

PHPのLaravelでも垂直スライスに近い構成が試行されています。例えば、GitHubやQiita記事では「UseCase」または「Features」フォルダを作り、その下に機能ごとにサブフォルダを設けるパターンが紹介されています。各サブフォルダにはコントローラ、DTO、ドメイン、リポジトリ、サービスを置き、機能単位のフォルダ構成を実現します。Laravelのルーティングやサービスコンテナ機能と組み合わせることで、垂直スライスに沿ったアーキテクチャを構築できます。なお、Laravel専用の公式テンプレートはありませんが、コミュニティのサンプルコードや記事を参考にすることで同様の構造が再現できます。

他言語/フレームワークでの例: Node.jsやRubyなどでの特徴

他のスタックでも、機能フォルダパターンは広く採用されています。Node.js（NestJSなど）では「Module単位」で機能を分割でき、Ruby on RailsでもEngineやService Objectを使って機能別にコードを整理する手法があります。これらのフレームワークでも「機能ごとにフォルダを分け、依存を限定する」という考え方は同じです。Vertical Slice固有のフレームワークサポートはないものの、各言語・フレームワークの標準機能で似た構造を実現できます。

OSSプロジェクトに見るVertical Slice: Modular MonolithやCQRSと連携

OSSの例では、モジュラーモノリス構成にVertical Sliceを組み合わせるケースがあります。例えば、Rusev氏が提供するeコマースモノリス例では、DDDやCQRSと共にVertical Sliceアーキテクチャが導入されています。またGitHub上のモノリスサンプルでは、ドメインごとに独立した垂直スライスを作成し、機能追加時に既存コードを変更しない実装が行われています。これらはすべて、Vertical Sliceの基本理念である「機能単位での独立開発」を反映しており、実践的な学習材料となります。

スキャフォールディングツール: Vertical Slice構造を自動生成する支援

開発効率化のために、垂直スライス構造を自動生成するツールやテンプレートも登場しています。.NETでは既述のVertical Sliceテンプレートが該当し、プロジェクト作成時に基本フォルダとサンプルコードを生成します。LaravelやJavaScriptでは、プロジェクトジェネレータ（Yeomanジェネレータなど）で「Featureフォルダ構成」の雛形を生成するものも利用できます。これらスキャフォールディングツールを使うと、プロジェクト立ち上げ時から垂直スライス設計をすばやく導入できるため、特に大規模開発の初期に有効です。

適用シーンや向いているプロジェクト

適用シーン1: 複数機能頻繁変更のアジャイル開発プロジェクト

Vertical Sliceはアジャイル環境で威力を発揮します。機能追加や仕様変更が頻繁に発生するプロジェクトでは、各スライスが小さく独立しているほど迅速に対応できます。たとえばEコマースサイトにおいて「商品登録」「在庫更新」「注文処理」といった機能はそれぞれ独立したスライスとし、スプリント毎に個別に開発・リリースすることが可能です。この方式では1つの機能に集中できるため、開発スピードが向上しリリースサイクルが短縮されます。

適用シーン2: 大規模モノリスを段階的にマイクロサービス化する場合

大規模なレガシーモノリスでは、Vertical Sliceを導入することで「機能別のモジュール化」が進み、将来的なマイクロサービス移行の準備ができます。機能単位に独立したスライスとして設計しておけば、必要に応じてそのスライスを切り出しマイクロサービス化しやすくなります。例えば、継続的に負荷が増加する特定機能（検索機能やレポート機能など）を最初から機能別に分離しておくことで、後から個別のサービスに移行する際の手間を大幅に削減できます。

チーム要件: リファクタリングに習熟した開発チームが必要

Vertical Sliceは単なるフォルダ分割だけでなく、リファクタリングとドメイン設計への深い理解を要求します。チームがこの手法に習熟していないと、逆に不適切な使い方で複雑化を招く恐れがあります。特にDDDの経験やCI/CDの成熟度、テスト文化がないチームではVertical Sliceのメリットを享受しにくくなります。したがって導入前にはチームの技術的背景や教育体制を整備し、Vertical Sliceの適切な適用条件を満たすことが重要です。

不向きなケース: 単一機能アプリや高度なドメインモデリング不要な場面

逆に、機能が少なく内部でほとんど変更が発生しない単純な小規模アプリでは、Vertical Sliceは過剰設計になる可能性があります。また、ビジネスロジックが非常に薄くCRUDだけが主であるような場合、レイヤー分割だけで十分なこともあります。このようなケースではVertical Slice化による構成の複雑化を避け、従来型のシンプルな構造を維持する判断も一つの方法です。

プロジェクト戦略との整合: モノリス・マイクロサービス選択との関係

Vertical Sliceはあくまでアプリケーション内部の設計手法であり、モノリスかマイクロサービスかといったアーキテクチャ戦略とは直接の代替関係ではありません。しかし、垂直スライス化されたモノリスはモジュラーモノリスとも呼ばれ、マイクロサービス移行への橋渡しともなり得ます。プロジェクトがどちらの形態を選ぶにせよ、垂直スライスで機能を整理しておけば、機能単位の独立度が高まり、いずれかの形態へスムーズに適応できるというメリットがあります。