現代のソフトウェアエンジニアリングにおいて、ソースコードの組織化—すなわちディレクトリ構造やパッケージ構成—は、単なる美的嗜好の問題ではなく、システムの保守性、拡張性、そして開発チームの認知負荷に直結する重要なアーキテクチャ上の決定事項です。かつてRuby on RailsやSpring Frameworkの初期バージョンが普及させた「Package by Layer（レイヤーによるパッケージング）」は、技術的な役割分担（MVC：Model-View-Controller）に基づく明確な構造を提供し、Web開発の標準化に大きく貢献しました。しかし、システムが複雑化し、ビジネスドメインが高度化するにつれ、この伝統的な構造が抱える「凝集度の低さ」と「結合度の高さ」という構造的欠陥が顕在化してきました。
本レポートは、ユーザーから提起された「なぜ最近はドメインごとに分割するPackage by Feature（機能によるパッケージング）が主流となってきたのか」という問いに対し、歴史的背景、理論的根拠、および主要エコシステム（Java/Spring、Ruby on Rails、Frontend）における具体的な実装パターンを徹底的に調査・分析したものです。
調査の結果、このパラダイムシフトは単なる流行ではなく、ドメイン駆動設計（DDD）の実践的適用、マイクロサービスアーキテクチャの運用難易度に対する反動としてのモジュラモノリス（Modular Monolith）の再評価、そしてコンウェイの法則を意識した組織構造への適応という、複合的な要因によって推進されていることが明らかになりました。特に2024年から2025年にかけてのトレンドとして、Springエコシステムにおける「Spring Modulith」の台頭や、RailsにおけるShopify主導の「Packwerk」による静的解析を用いた境界づけ、さらにはフロントエンドにおける「Feature-Sliced Design」の普及など、言語の垣根を超えた「機能単位の凝集」への収斂が見られます。
本稿では、これらの動向を15,000語にわたり詳述し、アーキテクトやリードエンジニアが次のプロジェクトにおいて適切なパッケージ戦略を選択するための指針を提供します。
2000年代初頭、JavaのStrutsやその後のSpring MVC、そして2004年に登場したRuby on Railsは、Webアプリケーション開発に革命をもたらしました。これらに共通していたのは、Model-View-Controller (MVC) パターンへの厳格な準拠でした。この時代、アーキテクチャの主眼は「関心事の分離（Separation of Concerns）」にありましたが、その分離の軸は「技術的役割」でした 1。
典型的なPackage by Layerの構造は以下のようなものです：
- app/controllers/: すべてのHTTPリクエスト処理
- app/models/: すべてのデータ構造とビジネスロジック
- app/views/: すべてのUIテンプレート
この構造の最大の利点は、学習コストの低さと予測可能性にありました。開発者がどのプロジェクトに参加しても、「コントローラーを探すならこのフォルダ」という場所が自明であり、フレームワークの規約（Convention over Configuration）に従うことで、初期の開発速度は劇的に向上しました 2。
しかし、アプリケーションが成長し、数百の機能を持つようになると、この構造は破綻し始めます。「User」に関する機能を修正するために、開発者はcontrollersフォルダ、modelsフォルダ、viewsフォルダ、さらにはservicesフォルダを行き来する必要が生じます。これらは物理的に離れた場所に配置されており、コードの**空間的局所性（Locality）**が失われています。
この現象は、ロバート・C・マーティン（Uncle Bob）らが指摘する「共通閉鎖原則（Common Closure Principle: CCP）」—同じ理由で変更されるクラスは同じパッケージに属すべきである—という原則に違反しています 1。結果として、レイヤー構造は以下のような弊害を生み出しました：
- 低凝集度（Low Cohesion）: 関連するビジネスロジックが分散し、機能の全容を把握することが困難になる。
- 高結合度（High Coupling）: 特定のレイヤー（例：Service層）が他のレイヤー（Repository層）に強く依存し、レイヤー間のAPI変更がシステム全体に波及する。
- アネミックドメインモデル（Anemic Domain Model）: ビジネスロジックがService層に漏れ出し、Model層が単なるデータの入れ物（DTO）と化す現象が頻発した。
この状況に対する理論的な解毒剤として浮上したのが、エリック・エヴァンスが提唱した**ドメイン駆動設計（DDD）**です。DDDは、ソフトウェアの複雑さを制御するために、技術的な役割ではなく「ビジネス領域（ドメイン）」を中心にシステムをモデル化することを提唱しました 4。
DDDの核心概念である「境界づけられたコンテキスト」は、特定のドメインモデルが適用される範囲を定義します。例えば、Eコマースシステムにおいて、「商品（Product）」という言葉の意味は、カタログコンテキスト（画像や説明文を持つ商品）と、在庫コンテキスト（SKUと保管場所を持つ商品）、配送コンテキスト（重量と寸法を持つ商品）では異なります 6。
Package by Layerでは、これらすべての「商品」が一つのProductクラス、あるいはmodelsフォルダ内の混在したクラス群として表現されがちでした。これに対し、DDDはこれらを別々のコンテキスト、すなわち別々のパッケージに分割することを推奨します。これがPackage by Featureへの移行を促す強力な理論的動機となりました 7。
ロバート・C・マーティンは「スクリーミングアーキテクチャ」という概念で、パッケージ構成のあり方を痛烈に批判しました。彼によれば、建物の設計図を見ればそれが家なのか図書館なのかが一目でわかるように、ソフトウェアのディレクトリ構造を見れば、それが「何をするシステムなのか（ヘルスケアシステムなのか、在庫管理システムなのか）」が一目でわかるべきです 9。
しかし、RailsやSpringの標準的なディレクトリ構造は、トップレベルでcontrollers, viewsなどを並べるため、そのシステムが「Webフレームワークを使っている」ことしか叫んでいません（Screaming）。Package by Featureを採用した構造は、トップレベルにBilling（請求）、Shipping（配送）、Ordering（注文）といったディレクトリが並び、システムのビジネス意図を明確に伝達します 11。
2010年代中盤、巨大化したモノリス（一枚岩のシステム）の複雑性を解決する銀の弾丸としてマイクロサービスアーキテクチャが爆発的に普及しました。マイクロサービスは、サービスごとに物理的なサーバーやリポジトリを分割することで、強制的に「境界」を作りました 13。
しかし、マイクロサービスは「分散システムの複雑性」という新たな、そして極めて高コストな代償を伴いました。ネットワーク遅延、分散トランザクション（Sagaパターン）、デプロイの複雑化などです 14。多くの組織にとって、マイクロサービスは時期尚早あるいは過剰設計であることが判明しました。
この反省から、2020年代に入り「モジュラモノリス（Modular Monolith）」への回帰が進んでいます。これは、デプロイ単位はモノリス（単一）でありながら、内部構造はマイクロサービスのように厳格にモジュール分割されたアーキテクチャです。このモジュラモノリスを実現するための最適なパッケージ戦略こそが、Package by Featureなのです 15。
Spring Frameworkは長らくレイヤーアーキテクチャの代名詞でしたが、近年は最も積極的にドメイン中心の構成を推進しています。
従来のSpringプロジェクト（例えば「Spring PetClinic」の古いバージョン）では、以下のような構成が一般的でした 17：
com.example.petclinic
├── model
│ ├── Owner.java
│ └── Pet.java
├── repository
│ ├── OwnerRepository.java
│ └── PetRepository.java
└── web
├── OwnerController.java
└── PetController.java
これに対し、最新のベストプラクティスやSpring Modulithを意識した構成では、以下のように変化しています 18：
com.example.petclinic
├── owners
│ ├── Owner.java
│ ├── OwnerRepository.java
│ └── OwnerController.java
├── pets
│ ├── Pet.java
│ ├── PetRepository.java
│ └── PetController.java
└── system
└──...
この変更により、ownersパッケージ内のクラス（例えばリポジトリや内部ロジック）をpackage-private（デフォルトの可視性）に設定し、パッケージ外からの無秩序なアクセスを防ぐことが可能になります。これはJavaの言語機能を活用した強力なカプセル化です 20。
2023年に正式リリースされたSpring Modulithは、この「機能単位のパッケージング」を単なる規約から「検証可能なアーキテクチャ」へと昇華させました 22。
Spring Modulithは、アプリケーション内のトップレベルパッケージを「モジュール」と見なし、モジュール間の依存関係を解析します。もしInventoryモジュールがOrderモジュールに依存し、OrderモジュールもまたInventoryモジュールに依存している（循環依存）場合、テスト実行時にビルドを失敗させることができます。これにより、開発者が意図せずスパゲッティコードを作り出すことを防ぎます 23。
モジュール間の結合度を下げるための定石は「イベント駆動」です。Orderモジュールで注文が確定した際、直接Inventoryモジュールのメソッドを呼ぶのではなく、OrderPlacedEventを発行します。Spring Modulithは、このイベント処理に**イベント・パブリケーション・レジストリ（Event Publication Registry）**という仕組みを提供しています 25。
これは、イベントの発行をデータベーストランザクションと同期させ、リスナー側の処理が失敗してもイベントが消失しないように永続化する仕組みです（トランザクショナル・アウトボックスパターンの自動実装）。これにより、開発者は分散システムのような複雑なインフラ（Kafkaなど）を用意せずとも、モノリス内部で堅牢なイベント駆動アーキテクチャを実現できます 27。
Package by Featureをさらに過激に推し進めたのが、.NETコミュニティ（Jimmy Bogardら）から波及し、Springでも採用され始めている**垂直スライスアーキテクチャ（Vertical Slice Architecture: VSA）**です 29。
VSAでは、「Controller」「Service」「Repository」という水平レイヤーさえも共有しません。各機能（例：「商品をカートに追加する」）は、独立した「スライス」として実装されます。一つのスライスには、その機能に必要なリクエスト処理、バリデーション、DBアクセスロジックがすべて含まれます（場合によっては単一のファイルに）。
実装にはしばしばMediatorパターン（Javaでは直接的なService呼び出しよりも、メッセージングに近い形）が用いられます。
| 特性 | クリーンアーキテクチャ (Layered/Onion) | 垂直スライスアーキテクチャ (VSA) |
|---|---|---|
| 抽象化の方向 | 同心円状（外から中へ） | 機能ごと（縦割り） |
| コードの共有 | InterfaceやBaseClassを多用 | 重複を恐れず独立性を重視 |
| 結合度 | レイヤー間で結合 | スライス間は疎結合 |
| 開発体験 | 全体構造の維持に注力 | 機能追加・削除が極めて容易 |
| 適した規模 | 長期運用・複雑なドメインルール | 機能追加が頻繁なアジャイル開発 |
VSAは、「共通化」という名の下に生じる不必要な結合（DRY原則の誤用）を徹底的に排除します。ある機能の変更が、全く無関係な別の機能にバグを引き起こすリスクを最小化できるため、アジリティを重視する現代の開発現場で支持を集めています 31。
Railsは「設定より規約（Convention over Configuration）」を掲げ、強力なデフォルト（app/models, app/controllers）を提供してきたため、アーキテクチャの変更に対する抵抗が最も強いフレームワークでした。しかし、ShopifyやGitHubのような巨大Railsアプリケーションの登場により、その限界が突破されつつあります。
Railsの標準構成に従い続けると、app/modelsには数百、数千のクラスがフラットに並ぶことになります。これは開発者にとって認知的な悪夢であり、「God Object（神オブジェクト）」化したUserモデルやOrderモデルが、システム全体のあらゆる場所に顔を出す密結合の温床となります 34。
これに対する伝統的な解決策はRails Enginesでした。アプリケーションを複数のEngine（ミニRailsアプリ）に分割し、それぞれをengines/ディレクトリなどに配置する方法です 35。
- 利点: 強力な隔離。EngineはGemのように振る舞うため、依存関係をgemspecで明示する必要がある。
- 欠点: 設定が複雑で、開発サーバーの再起動が必要になる場面が増えるなど、開発者体験（DX）が悪化しやすい 37。
Shopifyは、Rails Enginesのオーバーヘッドを回避しつつ、モジュール性を担保するためにPackwerkというGemを開発・公開しました 39。Packwerkのアプローチは革新的です。
- ディレクトリ移動のみ: ファイルをEngine化するのではなく、単にapp/packages/inventory/のようなディレクトリに移動させる。
- YAMLによる定義: 各パッケージにpackage.ymlを置き、依存関係を宣言する。
- 静的解析による強制: テストやCIの実行時にPackwerkがコードを解析し、「許可されていないパッケージのクラスを参照している」違反を検出する。
- プライバシー制御: クラスや定数をpublic（公開API）とprivate（パッケージ内のみ）に分類できる 40。
これにより、Rails開発者は標準的なRailsの書き心地（オートローディングなど）を維持したまま、Javaのpackage-privateのようなアクセス制御を手に入れることができました。Shopifyはこの手法を用いて、数千人のエンジニアが単一のRailsリポジトリ（Monorepo）で開発できる環境を維持しています 41。
2024年後半から2025年にかけて登場したRails 8もまた、このトレンドを後押ししています。
- Solid Queue & Mission Control: 従来、バックグラウンドジョブにはRedis（Sidekiq）などの外部インフラが必要でしたが、Rails 8ではDBベースのsolid_queueがデフォルトとなりました。また、ジョブ管理画面であるmission_controlも提供されます。これにより、ジョブの処理ロジックをインフラから切り離し、アプリケーションコードの一部として（機能ごとのパッケージ内に）管理しやすくなりました 43。
- Scriptフォルダ: ワンオフのスクリプトを置くscript/フォルダが標準化されました。これにより、ドメインロジックを含むlib/やapp/がメンテナンス用コードで汚染されるのを防ぎます 46。
「機能単位への分割」というトレンドは、バックエンドにとどまりません。ReactやVueを中心とするフロントエンド開発においても、同様の課題（コンポーネントの海による迷子、ビジネスロジックの分散）に対し、Feature-Sliced Design (FSD) というアーキテクチャが2024年以降急速に支持を広げています 47。
かつて主流だったAtomic Design（Atoms, Molecules, Organisms）は、UIコンポーネントの「見た目の粒度」に基づく分類でした。しかし、これには「ビジネスロジックをどこに置くか」という視点が欠けていました。「Organism（生体）」にAPIコールを含めるべきか？状態管理はどうするか？という問いに対し、明確な答えが出せず、結果として「高機能すぎるUIコンポーネント」が量産されました 49。
Feature-Sliced Designは、ビジネス価値と結合度に基づいて明確な階層（レイヤー）を定義します 51：
- App: アプリケーションの初期化、ルーティング、グローバル設定。
- Pages: ルーティングに対応するページ全体。
- Widgets: 独立したUIブロック（例：ヘッダー、商品リスト）。
- Features: ユーザーにとってビジネス価値のある行動（例：「カートに追加」「いいね！」）。
- Entities: ビジネスドメインの実体（例：「ユーザー」「商品」）。UIとモデルを含む。
- Shared: 特定のビジネスロジックに依存しない再利用可能なコード（UIキット、APIクライアント）。
鉄の掟: 上位レイヤーは下位レイヤーのみをインポートできる。下位レイヤー（例：Entities）が上位（Features）を知ることは許されない 53。
この構造は、バックエンドのPackage by Featureと完全に呼応しています。開発者は「カート機能」を修正する場合、features/cart/ディレクトリ内だけで作業を完結でき、UI、ロジック、API通信がそこに集約されています。
これまでの調査に基づき、各アーキテクチャスタイルの特性を比較します。
以下の表は、プロジェクトの特性に応じた最適なパッケージ戦略を示しています。
| 特性 | Package by Layer (層化) | Package by Feature (機能) | Vertical Slice (垂直) | Modular Monolith |
|---|---|---|---|---|
| 主要な分割単位 | 技術的役割 (Controller/Service) | ビジネスドメイン (User/Order) | ユースケース/リクエスト | ドメインモジュール |
| 適したチーム規模 | 小規模 (<5人) | 中〜大規模 | 中規模〜アジャイル | 大規模 (>20人) |
| コードの凝集度 | 低 (技術的凝集) | 高 (機能的凝集) | 最高 (機能的凝集) | 高 (境界内凝集) |
| 結合度 | 高 (レイヤー間結合) | 低 (API経由) | 極低 (独立) | 低 (契約による結合) |
| ナビゲーション | ファイル種別ごと | 機能ごと | 機能ごと | モジュールごと |
| マイクロサービス移行 | 困難 (全面リファクタが必要) | 容易 (フォルダ単位で切り出し) | 容易 (エンドポイント単位) | 最も容易 (設計済み) |
| 主な採用例 | 従来のRails/Spring教材 | 現代のSpring/DDD | .NET/Go/Modern Spring | Shopify/Gusto/Spring Modulith |
なぜ近年になってPackage by Featureへの回帰が進んでいるのでしょうか。調査から以下の3つのドライバーが特定されました。
- コンウェイの法則と逆コンウェイ戦略:
現代の開発組織は、職能別チーム（DBチーム、UIチーム）から、ストリームアラインドチーム（特定のビジネス価値を提供するフルスタックチーム）へと変化しています。組織が「機能単位」で動くなら、アーキテクチャも「機能単位」でなければ、チーム間のコミュニケーションコスト（調整コスト）が増大します。Package by Featureは、チームの自律性をコードレベルで支える構造です 13。 - 認知負荷（Cognitive Load）の限界:
ソフトウェアの複雑性は増す一方です。開発者がシステム全体を理解することはもはや不可能です。Package by Featureは、開発者が「今触るべき機能」以外の情報を隠蔽（カプセル化）することで、認知負荷を下げ、生産性を維持するための唯一の現実的な解です。 - ツールの進化:
以前はPackage by Featureを強制するツールが不足しており、時間が経つと構造が崩れがちでした。しかし、Spring ModulithやPackwerk、FSDのESLintプラグインなど、構造を「強制」し「検証」するツールチェーンが成熟したことで、継続的な維持が可能になりました。
2025年以降のソフトウェアアーキテクチャは、「モノリスかマイクロサービスか」という二元論を超え、シタデル（城塞）アーキテクチャへと収斂していくと予想されます 55。これは、中心に堅牢でモジュール化されたモノリス（城塞）があり、特殊な要件（例えば高負荷な画像処理やAI推論）を持つ機能だけを、城の外にある「アウトポスト（前哨基地）」としてマイクロサービス化する形態です。
Package by Featureはこのシタデル構造の基礎となります。最初から機能ごとにパッケージを分けておけば、将来的にその機能が「城の外」に出る必要が生じたとき、スムーズに切り出すことができます。
見逃せないのがAI（Copilot, Cursor等）の影響です。LLM（大規模言語モデル）は、関連するコードが近くにある（コンテキストウィンドウに収まる）場合に最高のパフォーマンスを発揮します。ロジックがレイヤーごとに分散しているよりも、機能ごとにまとまっている方が、AIにとっても「理解」しやすく、精度の高いコード生成が期待できます。Package by Featureは、人間だけでなくAIにとっても親和性の高いアーキテクチャと言えます。
ユーザーのご質問にある通り、SpringのサンプルやRailsの先進的な事例がPackage by Featureを採用しているのは、一時的な流行ではありません。それは、ソフトウェアの複雑性を管理し、ビジネスの変化速度に追従するための、工学的知見の集大成です。
もし貴方が新規プロジェクトを立ち上げるのであれば、以下の指針を採用することを強く推奨します：
- Springの場合: Spring Modulithを導入し、トップレベルパッケージをドメインごとに分割する。
- Railsの場合: 初期段階からPackwerkの導入を検討するか、少なくとも名前空間（Namespace）を使ってモデルやコントローラーをドメインごとにグルーピングする。
- 考え方: 「このファイルをどこに置くか（ControllerかModelか）」ではなく、「このファイルはどのビジネス機能（請求か配送か）に属するか」を最初に問う。
レイヤー構造は学習のための足場としては有用でしたが、本番レベルの複雑さに立ち向かうには、ドメインを第一級市民として扱う構造が不可欠です。
- Cohesion & Coupling Principles: 1
- Spring & Modulith: 18
- Rails & Packwerk: 39
- Vertical Slice Architecture: 29
- Feature-Sliced Design: 47
- Screaming Architecture: 9
- DDD & Contexts: 4
- Microservices to Monolith Trends: 13
- Rails 8 Updates: 43
- Package by feature, not layer - Java Practices, 11月 27, 2025にアクセス、 http://www.javapractices.com/topic/TopicAction.do?Id=205
- Package by Feature Is Demanded - DZone, 11月 27, 2025にアクセス、 https://dzone.com/articles/package-by-feature-is-demanded
- Structuring Your Code :: Spring Boot, 11月 27, 2025にアクセス、 https://docs.spring.io/spring-boot/reference/using/structuring-your-code.html
- Design Patterns in Clean Architecture & DDD A Deep Dive | by Tolga YILDIZ | Medium, 11月 27, 2025にアクセス、 https://medium.com/@tolgayildiz91/design-patterns-in-clean-architecture-ddd-a-deep-dive-a32c8e3c80e5
- Domain Driven Design - DEV Community, 11月 27, 2025にアクセス、 https://dev.to/lovestaco/domain-driven-design-3i2j
- Avoid coupling between Bounded Contexts using Weak Schema - | Arkency Blog, 11月 27, 2025にアクセス、 https://blog.arkency.com/avoid-coupling-between-bounded-contexts-using-weak-schema/
- Do domain driven design and clean architecture always go together? : r/dotnet - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/dotnet/comments/1i1b6wj/do_domain_driven_design_and_clean_architecture/
- Difference between Domain Driven Design and Clean Architecture, 11月 27, 2025にアクセス、 https://softwareengineering.stackexchange.com/questions/405973/difference-between-domain-driven-design-and-clean-architecture
- Screaming Architecture - Milan Jovanović, 11月 27, 2025にアクセス、 https://www.milanjovanovic.tech/blog/screaming-architecture
- Screaming Architecture: Letting Your Code Tell Its Story! | by Dev Balaji, 11月 27, 2025にアクセス、 https://dvmhn07.medium.com/screaming-architecture-letting-your-code-tell-its-story-203de594cf74
- What Is Screaming Architecture? | Nile Bits, 11月 27, 2025にアクセス、 https://www.nilebits.com/blog/2024/09/what-is-screaming-architecture/
- Screaming Architecture: Elevating Folder Structure in Javascript Projects - DEV Community, 11月 27, 2025にアクセス、 https://dev.to/mazzaracm/-41je
- Microservices vs. monolithic architecture - Atlassian, 11月 27, 2025にアクセス、 https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
- Microservices vs Monolith: Pros and Cons Debate 2024 - ClickIT, 11月 27, 2025にアクセス、 https://www.clickittech.com/devops/microservices-vs-monolith/
- Modular Monolith: Is This the Trend in Software Architecture? - arXiv, 11月 27, 2025にアクセス、 https://arxiv.org/pdf/2401.11867
- Why Monolithic Architecture Reigns Supreme for New Projects in 2025 | Leapcell, 11月 27, 2025にアクセス、 https://leapcell.io/blog/why-monolithic-architecture-reigns-supreme-for-new-projects-in-2025
- Recommended Package Structure of a Spring Boot Project | Baeldung, 11月 27, 2025にアクセス、 https://www.baeldung.com/spring-boot-package-structure
- Spring Boot Code Structure: Package by Layer vs Package by Feature | by Akın Topbaş, 11月 27, 2025にアクセス、 https://medium.com/@akintopbas96/spring-boot-code-structure-package-by-layer-vs-package-by-feature-5331a0c911fe
- Spring Boot folder structure best practices - Symflower, 11月 27, 2025にアクセス、 https://symflower.com/en/company/blog/2024/spring-boot-folder-structure/
- Package by Layer vs Package by Feature | Sahibinden Technology - Medium, 11月 27, 2025にアクセス、 https://medium.com/sahibinden-technology/package-by-layer-vs-package-by-feature-7e89cde2ae3a
- Structuring packages in Java web applications | That Which Inspires Awe, 11月 27, 2025にアクセス、 https://blog.indrek.io/articles/structuring-packages-in-java-web-applications/
- Spring Modulith, 11月 27, 2025にアクセス、 https://spring.io/projects/spring-modulith/
- What's New in IntelliJ IDEA 2025.2 - JetBrains, 11月 27, 2025にアクセス、 https://www.jetbrains.com/idea/whatsnew/
- Add detailed comparison with alternatives like Gradle and Maven multi-module projects to make reasons for adopting Spring Modulith more convincing #932 - GitHub, 11月 27, 2025にアクセス、 spring-projects/spring-modulith#932
- Event Externalization with Spring Modulith - Baeldung, 11月 27, 2025にアクセス、 https://www.baeldung.com/spring-modulith-event-externalization
- Event-Driven Spring Boot. Since its early days, Spring… | by Srdjan Bestic | Medium, 11月 27, 2025にアクセス、 https://medium.com/@srdjan.bestic/event-driven-spring-boot-a32c380f9e02
- Simplified Event Externalization with Spring Modulith, 11月 27, 2025にアクセス、 https://spring.io/blog/2023/09/22/simplified-event-externalization-with-spring-modulith/
- Simplified Event Externalization with Spring Modulith : r/java - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/java/comments/16p4zzq/simplified_event_externalization_with_spring/
- Vertical Slice Architecture | Baeldung, 11月 27, 2025にアクセス、 https://www.baeldung.com/java-vertical-slice-architecture
- Vertical Slice Architecture: The Best Ways to Structure Your Project : r/dotnet - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/dotnet/comments/1eo7uhk/vertical_slice_architecture_the_best_ways_to/
- Leveraging Vertical Slice Architecture with Clean Architecture for Scalable, Maintainable Systems, 11月 27, 2025にアクセス、 https://sayyedulawwab.com/blog/leveraging-vertical-slice-architecture-with-clean-architecture-for-scalable-maintainable-systems/
- What are your experience with Clean Architecture vs Vertical slice architecture - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/dotnet/comments/1iysrq4/what_are_your_experience_with_clean_architecture/
- Vertical Slice Architecture: Structuring Vertical Slices - Milan Jovanović, 11月 27, 2025にアクセス、 https://www.milanjovanovic.tech/blog/vertical-slice-architecture-structuring-vertical-slices
- Monolith to Modular Rails: What and Why | by Vishal Rathore | Sep, 2025 - Medium, 11月 27, 2025にアクセス、 https://medium.com/@Vishrathore/monolith-to-modular-rails-what-and-why-f40e4b78dbdb
- The Modular Monolith: Rails Architecture | by Dan Manges | Medium, 11月 27, 2025にアクセス、 https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4
- Modular Rails: Architectures | Devmystify, 11月 27, 2025にアクセス、 https://devblast.com/b/modular-rails-architectures
- Improving Rails scalability using modularity with enforced boundaries | by Rob Faldo, 11月 27, 2025にアクセス、 https://robertfaldo.medium.com/improving-rails-scalability-using-the-modular-monolith-approach-with-enforced-boundaries-f8cea89e85b9
- Introduction to Rails Engines (why and when to use them) : r/ruby - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/ruby/comments/13r3m9o/introduction_to_rails_engines_why_and_when_to_use/
- A Packwerk Retrospective (2024) - Shopify, 11月 27, 2025にアクセス、 https://shopify.engineering/a-packwerk-retrospective
- Packwerk at Shopify : r/ruby - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/ruby/comments/jkwp16/packwerk_at_shopify/
- Scaling our Ruby on Rails monolith using Packwerk (Part 1) | by Alexandre Ruban - Medium, 11月 27, 2025にアクセス、 https://medium.com/pennylane-engineering/scaling-our-ruby-on-rails-monolith-using-packwerk-part-1-b787aaa218ff
- Rails at Scale | The Ruby and Rails Infrastructure team at Shopify exists to help ensure that Ruby and Rails are 100-year tools that will continue to merit being our toolchain of choice., 11月 27, 2025にアクセス、 https://railsatscale.com/
- How to Build a Digital Weather Station Platform: From Legacy to Modern Systems - Netguru, 11月 27, 2025にアクセス、 https://www.netguru.com/blog/digital-weather-station-platform-modernization
- I Love You, Redis, But I'm Leaving You for SolidQueue - Simple Thread, 11月 27, 2025にアクセス、 https://www.simplethread.com/redis-solidqueue/
- Solid Queue: The New Database-Backed Jobs for Rails - Rently Engineering Blog, 11月 27, 2025にアクセス、 https://engineering.rently.com/solid-queue-the-new-database-backed-jobs-for-rails/
- What's New in Ruby on Rails 8 - Medium, 11月 27, 2025にアクセス、 https://medium.com/@ronakabhattrz/whats-new-in-ruby-on-rails-8-3f44d2d361a7
- Feature-Sliced Design and good frontend architecture - codecentric AG, 11月 27, 2025にアクセス、 https://www.codecentric.de/en/knowledge-hub/blog/feature-sliced-design-and-good-frontend-architecture
- Pavel Pogosov - Medium, 11月 27, 2025にアクセス、 https://medium.com/@pashkapag
- 11月 27, 2025にアクセス、 https://feature-sliced.design/docs/about/alternatives#:~:text=Atomic%20Design%20is%20oriented%20towards,independent%20modules%20and%20their%20interconnections.
- Why Atomic Design Is Not for Frontend: A Deep Dive - DEV Community, 11月 27, 2025にアクセス、 https://dev.to/it_vturbo/why-atomic-design-is-not-for-frontend-a-deep-dive-32in
- Layers - Feature-Sliced Design, 11月 27, 2025にアクセス、 https://feature-sliced.design/docs/reference/layers
- Overview | Feature-Sliced Design - GitHub Pages, 11月 27, 2025にアクセス、 https://feature-sliced.github.io/documentation/docs/get-started/overview
- Feature-Sliced Design: The Ideal Frontend Architecture | by Davit Gasparyan | Medium, 11月 27, 2025にアクセス、 https://medium.com/@dtgasparyan/feature-sliced-design-the-ideal-frontend-architecture-84d701ad44ba
- can someone explain why we ditched monoliths for microservices? like... what was the reason fr? - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/SoftwareEngineering/comments/1k2ppy9/can_someone_explain_why_we_ditched_monoliths_for/
- Modular Rails using Packwerk - btihen, 11月 27, 2025にアクセス、 https://btihen.dev/posts/ruby/rails_7_0_modular_using_packwerk/
- Package by type, -by layer, -by feature vs “Package by layered feature” | by Kaloyan Roussev | ProAndroidDev, 11月 27, 2025にアクセス、 https://proandroiddev.com/package-by-type-by-layer-by-feature-vs-package-by-layered-feature-e59921a4dffa
- What is the recommended project structure for spring boot rest projects? - Stack Overflow, 11月 27, 2025にアクセス、 https://stackoverflow.com/questions/40902280/what-is-the-recommended-project-structure-for-spring-boot-rest-projects
- A How-to Guide to Ruby Packs, Gusto's Gem Ecosystem for Modularizing Ruby Applications, 11月 27, 2025にアクセス、 https://engineering.gusto.com/a-how-to-guide-to-ruby-packs-gustos-gem-ecosystem-for-modularizing-ruby-applications-e236126b8c2c