gemini-package-1.md

現代ソフトウェアアーキテクチャの進化：レイヤードモノリスから垂直スライス、そしてコンポーネント指向へのパラダイムシフトに関する包括的調査報告書

1. 序論：ソフトウェアの複雑性と凝集度の再定義

ソフトウェアエンジニアリングの歴史は、本質的に「複雑性」との闘争の歴史であると言えます。過去20年以上にわたり、業界はこの複雑性を管理するための主要な戦略として「水平方向のレイヤー化（Horizontal Layering）」を採用してきました。これは、プレゼンテーション、ビジネスロジック、データアクセスといった技術的関心事に基づいてコードを物理的に分離する手法であり、C#のN階層アーキテクチャや初期のWebフロントエンド開発において支配的なパラダイムでした。しかし、アプリケーションのインタラクティビティが増大し、ビジネス要件の変化の速度が加速するにつれて、この水平方向の境界線は開発の速度を妨げる要因となりつつあります。

本報告書は、バックエンド（特にC#/.NETエコシステム）、Webフロントエンド、そしてスタイリング（CSS）という3つの主要な領域において、アーキテクチャのトレンドがどのように変化しているかを包括的に調査・分析したものです。調査の結果、これら全ての領域において、「技術的な種類の分離」から「機能的な意味の凝集（Locality of Behavior）」への巨大なパラダイムシフトが進行していることが明らかになりました。

バックエンドでは、厳格な抽象化を重視するクリーンアーキテクチャから、機能単位でコードを垂直に切り出す「垂直スライスアーキテクチャ（Vertical Slice Architecture: VSA）」への移行が見られます。フロントエンドでは、jQuery時代の技術別分離（HTML/JS/CSS）から、React/Vueに代表されるコンポーネント指向（機能単位の統合）へと移行し、さらにディレクトリ構造も「機能ベース（Feature-based）」が標準化しつつあります。スタイリングにおいては、Atomic Designのような階層的分類から、Tailwind CSSに代表される「ユーティリティファースト」への移行が進み、コンポーネントとスタイルがかつてないほど密結合する傾向にあります。

本稿では、これらの変化を単なる流行の変遷としてではなく、ソフトウェア設計における「凝集度（Cohesion）」と「結合度（Coupling）」の定義そのものの再評価として捉え、各領域の詳細な分析と将来の展望を論じます。

---

2. バックエンドアーキテクチャの変遷：C#/.NETを中心とした分析

C#および.NETエコシステムにおけるアーキテクチャの進化は、エンタープライズアプリケーション開発の歴史そのものを映し出しています。初期のデータ中心型のアプローチから、ドメイン駆動設計（DDD）の影響を受けたレイヤー化、そして現在の機能中心型のアプローチへの変遷を詳細に分析します。

2.1 N階層アーキテクチャ（N-Layer Architecture）の興亡

2000年代初頭から中盤にかけて、Microsoftの推奨するエンタープライズアーキテクチャの標準は「N階層アーキテクチャ」でした。これは、アプリケーションを以下の3つの主要なレイヤーに水平分割するものです。

1. プレゼンテーション層（Presentation Layer）: ユーザーインターフェース（ASP.NET Web Forms, MVC Controllers）を担当。
2. ビジネスロジック層（Business Logic Layer: BLL）: ビジネスルールをカプセル化した「Service」クラス群。
3. データアクセス層（Data Access Layer: DAL）: データベースとの通信を担当するRepositoryやDataSet。

2.1.1 階層化の理論的根拠とその破綻

このアーキテクチャの理論的根拠は「関心ごとの分離（Separation of Concerns: SoC）」にありました。データアクセスをビジネスロジックから分離することで、将来的なデータベースの変更や、異なるUI（WebとDesktopなど）からのロジック再利用が可能になると考えられていました1。

しかし、現実の開発現場では、この構造はしばしば「ラザニアコード」と呼ばれる状態を引き起こしました。例えば、「ユーザーのメールアドレスを変更する」という単純な機能を実装するために、開発者はプレゼンテーション層のViewModel、コントローラー、BLLのインターフェースと実装、DALのインターフェースと実装、そしてエンティティ定義と、全てのレイヤーを垂直に貫通して変更を加える必要がありました。これは、機能的な変更を行う際の「変更の及ぶ範囲（Axis of Change）」とアーキテクチャの境界線が直交していることを意味します。結果として、単一の機能を理解するために多数のファイルを行き来する必要が生じ、認知負荷が増大しました2。

また、BLL（Serviceクラス）はしばしば肥大化し、数千行に及ぶ「God Class（神クラス）」と化す傾向がありました。UserServiceのようなクラスには、ユーザー登録、パスワードリセット、プロフィール更新、管理者による削除など、文脈の異なるメソッドが無秩序に追加され、保守性を著しく低下させる要因となりました3。

2.2 クリーンアーキテクチャの台頭と「抽象化のコスト」

N階層アーキテクチャの結合度の高さ（特にDALへの依存）に対する反動として、2010年代にはRobert C. Martin氏らが提唱する「クリーンアーキテクチャ（Clean Architecture）」や「オニオンアーキテクチャ」が主流となりました。

2.2.1 依存性の逆転

クリーンアーキテクチャの核心は、依存性の方向を制御することにあります。従来のN階層では「UI → BLL → DAL → DB」と依存していましたが、クリーンアーキテクチャでは中心に「ドメイン（Domain）」を置き、全ての依存が内側（ドメイン）に向かうように構成します。インフラストラクチャ（DBやWebフレームワーク）は詳細事項とみなされ、ドメイン層が定義したインターフェース（IRepositoryなど）を外側の層が実装する形をとります5。これにより、ビジネスロジックはデータベースやフレームワークから完全に隔離され、テスト容易性が飛躍的に向上しました。

2.2.2 実践における課題：ボイラープレートの増大

しかし、クリーンアーキテクチャは高い「抽象化のコスト」を伴います。単純なCRUD操作であっても、リクエストモデル、ユースケース（Interactor）、出力ポート（Interface）、プレゼンター、ViewModelといった多数のオブジェクトを定義する必要があります。特に現代のWeb API開発においては、多くの操作が単なるデータの読み書きであり、重厚なドメインルールを必要としない場合も多々あります。そのような場合、クリーンアーキテクチャの各レイヤーは単にデータを右から左へ受け渡すだけの冗長なコードとなり、開発速度を低下させる要因となります7。また、レイヤー間のデータのマッピング（EntityからDTOへの変換など）に多くの労力が割かれ、本質的なビジネスロジックよりも「配管工事」に時間を費やす状況が生まれました8。

2.3 垂直スライスアーキテクチャ（Vertical Slice Architecture）への転換

現在、C#/.NETコミュニティで最も注目されているパラダイムシフトが「垂直スライスアーキテクチャ（VSA）」への移行です。Jimmy Bogard氏（MediatR, AutoMapperの作者）によって提唱されたこのアプローチは、水平方向のレイヤー化を撤廃し、機能（Feature）単位での垂直的な分割を推奨します9。

2.3.1 機能による凝集（Minimize Coupling between Slices）

VSAの基本原則は、「スライス間の結合を最小限にし、スライス内の結合を最大限にする（Minimize coupling between slices, and maximize coupling in a slice）」ことです12。従来のアーキテクチャでは、バリデーションロジック、データベースクエリ、ビジネスルールが別々のレイヤーに分散していましたが、VSAではこれらを単一の「機能フォルダ（Feature Folder）」に配置します。

典型的なVSAのプロジェクト構造は以下のようになります：

• Features/Orders/PlaceOrder/
  • PlaceOrderController.cs (またはMinimal APIエンドポイント)
  • PlaceOrderCommand.cs (リクエストDTO)
  • PlaceOrderHandler.cs (ロジック実装)
  • PlaceOrderValidator.cs (バリデーションルール)
  • PlaceOrderResponse.cs (レスポンスDTO)

このように関連する全てのコードを物理的に近くに配置する（Colocation）ことで、開発者はその機能がどのように動作するかを単一の場所で理解することができます。これは「凝集度」の概念を、技術的な種類の統一（全てのコントローラーをまとめる等）から、機能的な意味の統一へと再定義するものです2。

2.3.2 MediatRとCQRSの活用

.NETにおけるVSAの実装は、CQRS（Command Query Responsibility Segregation）パターンとライブラリ「MediatR」と密接に関連しています。コントローラーはリクエストを受け取ると、処理を自分で実行せず、MediatRを通じてメッセージ（CommandまたはQuery）をディスパッチします。これにより、Webフレームワーク（ASP.NET Core）とビジネスロジックが完全に分離されます7。

特筆すべきは、VSAにおいては「共通化」に対する姿勢が根本的に異なる点です。例えば、読み取り専用のクエリ（Query）機能においては、ドメインモデルやリポジトリパターンを完全にバイパスし、DapperやEntity Frameworkを用いて直接データベースからDTO（Data Transfer Object）へ射影することが推奨されます。これにより、不要な抽象化を排除し、パフォーマンスと開発効率を最大化します17。

2.3.3 DRY原則の再解釈と共有ロジックの扱い

VSAに対する一般的な批判として「コードの重複（DRY原則違反）」が挙げられます。しかし、VSAの支持者は「知識の重複」と「機械的な重複」を区別します。異なる機能（スライス）が似たようなコードを持っているとしても、それらが異なる理由で変更される可能性があるならば、無理に共通化するよりも重複を許容する方が、結合度を下げる上で有益であると考えます（これは「偶然の重複」と呼ばれます）19。

一方で、認証、ロギング、トランザクション管理などの「横断的関心事（Cross-Cutting Concerns）」については、MediatRのPipeline BehaviorやASP.NET Coreのミドルウェアを用いて処理することで、各スライスのコードをクリーンに保ちます。また、ドメインの中核となる重要なビジネスルール（例えば「在庫引当ロジック」など）については、複数のスライスから共有される「ドメインモデル」や「ドメインサービス」として実装し、各スライスから呼び出すハイブリッドなアプローチも一般的です10。

2.4 Go言語（Golang）における並行進化

C#におけるこの変化は孤立したものではありません。Go言語のエコシステムにおいても、同様の議論が展開されています。

2.4.1 「標準レイアウト」への懐疑

Goコミュニティでは長らくgolang-standards/project-layoutというリポジトリが事実上の標準として参照されてきました。このレイアウトはcmd, pkg, internal, apiといったディレクトリ構造を定義していますが、これはJavaやC#の従来の構造に近く、Goの哲学である「Simplicity」と相反するという批判が、Goのコアチーム（Russ Cox氏など）からもなされています21。

2.4.2 Package by Featureの採用

Goにおいても、レイヤーごと（Handlers, Models, Repositories）にパッケージを分けるのではなく、機能ごと（Users, Billing, Notifications）にパッケージを分ける「Package by Feature」のアプローチが推奨されつつあります。Goでは循環依存がコンパイルエラーとなるため、レイヤー構造は依存関係の管理が難しくなりがちですが、機能単位のパッケージ分割はカプセル化（internalパッケージの活用など）を促進し、各パッケージの独立性を高めることができます3。これはC#におけるVSAと同じく、ドメインの境界に沿ったコード配置を志向する動きと言えます。

---

3. Webフロントエンドの進化：技術の分離からコンポーネントの統合へ

Webフロントエンドの世界における変化は、バックエンド以上に劇的です。jQueryによるDOM操作の時代から、MVCフレームワークの模索を経て、React/Vueによるコンポーネント指向へと至る道程は、UI開発における「関心ごとの分離」の意味を根本から覆しました。

3.1 jQuery時代：技術による分離と命令的DOM操作

2000年代後半から2010年代初頭にかけてのフロントエンド開発は、jQueryを中心とした「命令的（Imperative）」なアプローチが主流でした。当時のベストプラクティスは、HTML（構造）、CSS（表現）、JavaScript（振る舞い）を完全に別々のファイルに分離することであり、これを「関心ごとの分離」と呼んでいました。

しかし、実際にはJavaScriptロジックはHTMLの構造（IDやクラス名）に強く依存していました。例えば、「#submit-btnをクリックしたら#error-msgを表示する」というロジックは、HTML側のIDが変更されれば即座に破綻します。このように、ファイルは分かれていても論理的な結合度は極めて高く、アプリケーションが大規模化するにつれて「jQueryスパゲッティ」と呼ばれる保守困難な状態に陥りました25。状態（State）はDOMの中に埋め込まれており（例：class="active"がついているかどうかで判断）、真実のソース（Source of Truth）が存在しないことも複雑性を増大させました。

3.2 MVC時代の模索：BackboneとAngularJS

Webアプリケーションがリッチになるにつれ、バックエンドの秩序をフロントエンドに持ち込もうとする動きが現れました。Backbone.jsや初期のAngularJS（v1）は、MV（Model-View-Controller/ViewModel）パターンを採用しました。これにより、データ（Model）と表示（View）の分離が進みましたが、依然として「技術による分離」のパラダイムに囚われていました。テンプレートはHTML文字列として扱われ、コントローラーとビューの間で状態を同期するための双方向データバインディングは、大規模アプリにおいて予測不可能な副作用やパフォーマンス問題を引き起こしました27。

3.3 React/Vueの衝撃：コンポーネント指向とコロケーション

Reactの登場は、フロントエンドアーキテクチャにおける最大の転換点でした。Reactは「技術（HTML/CSS/JS）を分離するのではなく、機能（コンポーネント）を分離すべきだ」という革命的な提言を行いました。

3.3.1 宣言的UIと関心ごとの統合

ReactやVueは「宣言的（Declarative）」なUI構築を可能にしました。開発者は「DOMをどう操作するか」ではなく、「状態（State）がどうあるべきか」を記述します。そして、HTML（JSX）、JavaScriptロジック、そして近年ではCSSまでもが単一のファイル（コンポーネント）内に同居（Colocation）するようになりました。
これにより、開発者はコンテキストスイッチなしに機能の実装に集中できるようになりました。「ボタン」コンポーネントを見れば、その構造、見た目、振る舞いの全てがそこに記述されています。これは、かつて「悪」とされた技術の混在ですが、実際には「機能的な凝集度」を極限まで高めるアプローチとして成功を収めました25。

3.4 状態管理の変遷とディレクトリ構造の進化

コンポーネント指向の確立後、焦点は「状態管理」と「ディレクトリ構造」へと移りました。

3.4.1 Reduxの栄枯盛衰とServer Stateの分離

初期のReactエコシステムでは、Reduxによる単一巨大ストアでの状態管理が標準とされました。しかし、Reduxのボイラープレート（Action, Reducer, Selector）の多さは、C#のN階層アーキテクチャと同様の問題（機能追加のために多数のファイルを修正する必要がある）を引き起こしました。
現在では、状態の種類に応じた適切なツールの使い分けが進んでいます。

• Server State: APIから取得したデータのキャッシュ管理には、TanStack Query (React Query) やSWRが用いられます。これにより、非同期処理の複雑さがコンポーネントから分離されました。
• UI State: モーダルの開閉などの局所的な状態は、useStateやuseReducerでコンポーネント内に閉じ込められます。
• Global Client State: アプリ全体で共有すべき真のグローバル状態（テーマ設定、ユーザーセッション）のみが、ZustandやContext APIで管理されます。

3.4.2 ディレクトリ構造のトレンド：Feature-based Architecture

jQuery/MVC時代の名残である「ファイルタイプによる分類（Components, Hooks, Pages, Utilsフォルダに分ける）」は、大規模開発においてスケーラビリティの問題に直面しました。機能に関連するファイルがプロジェクト全体に散らばってしまうためです。

これに対し、現在のトレンドは「Bulletproof React」リポジトリに代表される**「機能ベース（Feature-based）アーキテクチャ」**です。これはバックエンドのVSAと全く同じ思想に基づいています31。

推奨される構造例:
src/
features/
auth/ <-- 機能フォルダ
api/ <-- この機能固有のAPI定義
components/ <-- この機能でしか使わないコンポーネント
hooks/ <-- この機能固有のフック
routes/ <-- この機能のページルート
stores/ <-- この機能の状態管理
index.ts <-- 公開APIの定義
discussions/
users/
components/ <-- アプリ全体で共有される汎用UI部品（Button等）
lib/ <-- Axios等の設定
この構造の最大の利点は、「機能の削除（Deletability）」が容易であることです。ある機能を削除したい場合、features/xxxフォルダを削除するだけで済みます。また、各機能フォルダ内のindex.tsを通じて公開するものを制限することで、フロントエンド内でも「境界づけられたコンテキスト（Bounded Context）」を実現し、スパゲッティコード化を防ぐことができます34。

---

4. CSSアーキテクチャの進化とAtomic Designの再考

スタイリング（CSS）の領域においても、グローバルな名前空間の問題を解決するために様々な手法が提案されてきました。ユーザーからの要請にある「Atomic DesignがPackage by Layerとなる」という点を含め、最新のトレンドを分析します。

4.1 BEMからCSS Modulesへ：スコープの制御

初期のCSS設計では、BEM（Block Element Modifier）のような命名規則によって、擬似的に名前空間を作り出し、スタイルの衝突を防いでいました（例：.card__button--primary）。しかし、これは開発者の規律に依存しており、プロジェクトが長期化すると「使われていないCSS」が増大し続けるという問題がありました35。
Reactの普及と共に登場したCSS ModulesやCSS-in-JS（Styled Components等）は、ビルド時にクラス名をハッシュ化することで完全なローカルスコープを実現しました。これにより安全にスタイルを記述できるようになりましたが、依然として「CSSを書く」という作業自体（別ファイルへの記述やコンテキストスイッチ）は残りました。

4.2 Atomic Design：構造化の功罪と「レイヤー化」の問題

Brad Frost氏が提唱したAtomic Designは、UIを科学的な階層（Atoms, Molecules, Organisms, Templates, Pages）に分類するメンタルモデルを提供しました37。これはデザインシステムの構築には極めて有用でしたが、これをそのままディレクトリ構造（フォルダ構成）に適用することには多くの批判があります。

4.2.1 Atomic Designフォルダは「Package by Layer」である

ユーザーの指摘通り、src/components/atoms, src/components/molecules といったフォルダ分けは、本質的に「技術的な複雑さのレベル」によるレイヤー化（Package by Layer）に他なりません。
開発者は実装中に「この検索フォームはMoleculeなのかOrganismなのか？」という分類の議論（Bikeshedding）に時間を費やすことになります。また、あるコンポーネントが成長して複雑になった場合、それをmoleculesフォルダからorganismsフォルダに移動させる必要が生じ、それに伴うimportパスの修正が発生します。これはリファクタリングの摩擦となります38。
さらに、機能的な関連性が無視されがちです。「商品リスト」コンポーネント（Organism）と、その中でのみ使われる「商品カード」コンポーネント（Molecule）が、遥か離れたフォルダに配置されることになり、これはVSAやFeature-basedアーキテクチャが目指す「関連するもののコロケーション」に逆行します。

4.3 Tailwind CSSとユーティリティファースト：究極のコロケーション

現在、CSSアーキテクチャの最先端にあるのが、Tailwind CSSに代表されるユーティリティファーストのアプローチです。

4.3.1 意味論的命名からの脱却

Tailwindは、.btn-primaryのような意味論的なクラス名ではなく、.bg-blue-500, .p-4, .roundedといった視覚的機能を表すユーティリティクラスをHTMLに直接記述します。
これは一見すると「関心ごとの分離」に違反しているように見えますが、コンポーネント指向の文脈では「スタイルと構造は密結合であるべき」という思想に基づいています。Reactコンポーネントの中にスタイル定義が含まれることで、外部のCSSファイルに依存せず、そのコンポーネント単体で完全に動作・見た目が保証されます36。

4.3.2 Atomic Designとの融合と解消

Tailwindを採用する場合、従来のAtomic Design的なフォルダ構造は不要になる傾向があります。

• Atomsの役割: Tailwindのクラス列（px-4 py-2 bg-blue-500 roundedなど）をカプセル化したReactコンポーネント（<Button>など）が、実質的な「Atom」となります。これらはcomponents/uiやsharedフォルダに置かれます。
• Molecules/Organismsの解消: これらは特定の機能に結びついたコンポーネントであることが多いため、前述の「機能フォルダ（features/xxx/components）」の中に配置されます。

つまり、「汎用的なUI部品（Atoms相当）」と「特定機能のUI部品（Molecules/Organisms相当）」に二分し、前者を共有フォルダへ、後者を機能フォルダへ配置するスタイルが、現代のベストプラクティス（例えばshadcn/uiの採用など）となっています。これにより、Atomic Designの「概念」は維持しつつ、フォルダ構造としての「レイヤー化の弊害」を回避しています41。

---

5. 結論：Locality of Behavior（振る舞いの局所性）への回帰

本調査を通じて、C#バックエンド、Webフロントエンド、そしてCSSアーキテクチャの全てにおいて、共通する進化の方向性が確認されました。それは「Locality of Behavior（振る舞いの局所性）」の追求です。

1. C#: コントローラー、ロジック、データアクセスをレイヤーごとに分散させるのではなく、**「機能スライス」**として一箇所に集める。
2. Frontend: HTML、JS、CSSを技術ごとに分離するのではなく、「コンポーネント」として一箇所に集め、さらにそれらを「機能ディレクトリ」で管理する。
3. CSS: スタイルシートを別に管理するのではなく、**「ユーティリティクラス」**としてマークアップの直近に配置する。

これらの変化は、ソフトウェアの保守コストの大部分が「コードを書くこと」ではなく「コードを読み、理解し、変更すること」にあるという認識に基づいています。関連するコードが物理的に近くにあればあるほど、開発者の認知負荷は下がり、変更による予期せぬ副作用（回帰バグ）のリスクを低減できます。

かつて「美しい」とされた、厳格にレイヤー分けされたアーキテクチャや、完璧に抽象化されたドメインモデルは、変化の激しい現代のビジネス環境においては「過剰な複雑性」とみなされるようになりました。2025年の時点において、最も生産的でスケーラブルなアーキテクチャとは、「技術的な純粋さ」よりも「機能的なまとまり」を優先し、変更の容易さ（Modifiability）と削除の容易さ（Deletability）を中心に設計された構造であると結論付けられます。

表1: 各領域におけるアーキテクチャパラダイムの比較

領域	過去のパラダイム (Layered/Separated)	現代のパラダイム (Colocated/Vertical)	主な利点	代表的な技術・パターン
Backend (C#)	N-Layer Architecture, Clean Architecture	Vertical Slice Architecture (VSA)	機能ごとの凝集、認知負荷の低減、ボイラープレート削除	MediatR, Minimal APIs, Feature Folders
Frontend (JS)	Separation of Technologies (HTML/CSS/JS), MVC	Component-Based, Feature-Based Architecture	宣言的UI、機能のカプセル化、スケーラビリティ	React, Vue, Bulletproof React structure
Styling (CSS)	Semantic CSS (BEM), Global Stylesheets	Utility-First CSS, CSS-in-JS	スコープの安全性、スタイルの局所化、デッドコード排除	Tailwind CSS, Styled Components, CSS Modules
組織構造	Atomic Design (Directory by Atoms/Molecules)	Directory by Feature (UI components vs Feature components)	分類の迷い（Bikeshedding）の排除、ビジネスコンテキストとの一致	shadcn/ui, Feature-Sliced Design

31

引用文献

1. N-Layered vs Clean vs Vertical Slice Architecture: Choosing the Right Approach for .NET Projects in 2025, 11月 27, 2025にアクセス、 https://antondevtips.com/blog/n-layered-vs-clean-vs-vertical-slice-architecture
2. Vertical Slice Architecture in .NET Core: A Deep Dive into Theory, Pros, and Cons. - Medium, 11月 27, 2025にアクセス、 https://medium.com/@chauhanshubham19765/vertical-slice-architecture-in-net-core-a-deep-dive-into-theory-pros-and-cons-975bf8cc5cb5
3. 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
4. Vertical Slice Architecture and Comparison with Clean Architecture | by Mehmet Ozkaya, 11月 27, 2025にアクセス、 https://mehmetozkaya.medium.com/vertical-slice-architecture-and-comparison-with-clean-architecture-76f813e3dab6
5. 11月 27, 2025にアクセス、 https://antondevtips.com/blog/the-best-way-to-structure-your-dotnet-projects-with-clean-architecture-and-vertical-slices#:~:text=NET%20Projects%20with%20Clean%20Architecture%20and%20Vertical%20Slices,-Aug%2027%2C%202024&text=Clean%20Architecture%20aims%20to%20separate,features%20rather%20than%20technical%20layers.
6. The Best Way To Structure Your .NET Projects with Clean Architecture and Vertical Slices, 11月 27, 2025にアクセス、 https://antondevtips.com/blog/the-best-way-to-structure-your-dotnet-projects-with-clean-architecture-and-vertical-slices
7. # Choosing Between using Clean/Onion or Vertical Slice Architecture for Enterprise Apps in .NET : r/dotnet - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/dotnet/comments/lw13r2/choosing_between_using_cleanonion_or_vertical/
8. Why Vertical Slices Won't Evolve from Clean Architecture - Rico Fritzsche, 11月 27, 2025にアクセス、 https://ricofritzsche.me/why-vertical-slices-wont-evolve-from-clean-architecture/
9. Vertical Slice Architecture (Jimmy Bogard) - YouTube, 11月 27, 2025にアクセス、 https://www.youtube.com/watch?v=oAoaMlS1PWo
10. Vertical Slice Architecture - Jimmy Bogard, 11月 27, 2025にアクセス、 https://www.jimmybogard.com/vertical-slice-architecture/
11. Vertical Slice Architecture: Home, 11月 27, 2025にアクセス、 https://verticalslicearchitecture.com/
12. Vertical Slice Architecture - Milan Jovanović, 11月 27, 2025にアクセス、 https://www.milanjovanovic.tech/blog/vertical-slice-architecture
13. nadirbad/VerticalSliceArchitecture: Vertical Slice Architecture solution template in .NET 9 - GitHub, 11月 27, 2025にアクセス、 https://github.com/nadirbad/VerticalSliceArchitecture
14. sebajax/go-vertical-slice-architecture - GitHub, 11月 27, 2025にアクセス、 https://github.com/sebajax/go-vertical-slice-architecture
15. Building Scalable APIs with Vertical Slice Architecture in .NET | by Amit Naik - Medium, 11月 27, 2025にアクセス、 https://medium.com/expertminds/building-scalable-apis-with-vertical-slice-architecture-in-net-23f9d8c8a84e
16. 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/
17. Vertical slice architecture pitch | TKIT_dev, 11月 27, 2025にアクセス、 https://tkit.dev/2021/08/28/vertical-slice-architecture-pitch/
18. isaacOjeda/MinimalApiArchitecture: .NET 8 Minimal API with Vertical Slice Architecture - GitHub, 11月 27, 2025にアクセス、 https://github.com/isaacOjeda/MinimalApiArchitecture
19. Does Vertical Slice Architecture Violate the DRY Principle? - Stack Overflow, 11月 27, 2025にアクセス、 https://stackoverflow.com/questions/76766212/does-vertical-slice-architecture-violate-the-dry-principle
20. Vertical Slice Architecture In .NET using Cortex.Mediator and Minimal APIs | by Enes Hoxha, 11月 27, 2025にアクセス、 https://medium.com/@eneshoxha_65350/vertical-slice-architecture-in-net-using-cortex-mediator-and-minimal-apis-dd7fe575d46a
21. Golang project directory structure - Stack Overflow, 11月 27, 2025にアクセス、 https://stackoverflow.com/questions/46646559/golang-project-directory-structure
22. Russ Cox himself bewares that the "Standard Go Project Layout" is really not, 11月 27, 2025にアクセス、 https://dev.to/biros/comment/1gclo
23. Handling Circular Dependencies in Modular Monolithic Applications in Golang - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/golang/comments/1ed9eg3/handling_circular_dependencies_in_modular/
24. Should we use 'package by feature' structure with DDD? - Stack Overflow, 11月 27, 2025にアクセス、 https://stackoverflow.com/questions/55245747/should-we-use-package-by-feature-structure-with-ddd
25. Separation of Concerns: Rethinking the Blend of HTML, JavaScript, and CSS, 11月 27, 2025にアクセス、 https://dev.to/blakeanderson/separation-of-concerns-rethinking-the-blend-of-html-javascript-and-css-1bkp
26. The Evolution of Front-End Development: From HTML to Modern Frameworks - Medium, 11月 27, 2025にアクセス、 https://medium.com/@mattlcoleman88/the-evolution-of-front-end-development-from-html-to-modern-frameworks-110c995ec7fc
27. Frontend and Backend MVC Components Explained for Efficient Web Development, 11月 27, 2025にアクセス、 https://www.synlabs.io/post/frontend-and-backend-mvc-components-explained-for-efficient-web-development
28. The Evolution of Frontend Frameworks: From Vanilla JS to Modern Component-Based Architectures | by Raj Chaudhary | readytowork, Inc., 11月 27, 2025にアクセス、 https://articles.readytowork.jp/the-evolution-of-frontend-frameworks-from-vanilla-js-to-modern-component-based-architectures-ea8ade52ffc1
29. Why are modern frameworks component-based? : r/webdev - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/webdev/comments/wop7z4/why_are_modern_frameworks_componentbased/
30. What About Separation of Concerns? - Marko, 11月 27, 2025にアクセス、 https://markojs.com/docs/explanation/separation-of-concerns
31. alan2207/bulletproof-react: 🛡️ ⚛️ A simple, scalable ... - GitHub, 11月 27, 2025にアクセス、 https://github.com/alan2207/bulletproof-react
32. Why I Switched to a Feature-Based Folder Structure (And Why You Should Too), 11月 27, 2025にアクセス、 https://dev.to/hxnain619/why-i-switched-to-a-feature-based-folder-structure-and-why-you-should-too-3lpo
33. How I Structure my React Projects | by Riki Phukon - Medium, 11月 27, 2025にアクセス、 https://rikiphukon.medium.com/how-i-structure-my-react-projects-as-a-frontend-developer-22bd18e83f5b
34. 3 Folder Structures in React I've Used — And Why Feature-Based Is My Favorite, 11月 27, 2025にアクセス、 https://asrulkadir.medium.com/3-folder-structures-in-react-ive-used-and-why-feature-based-is-my-favorite-e1af7c8e91ec
35. CSS Architecture for Design Systems: From BEM to CSS Modules to Utility-First | by Roberto Moreno Celta, 11月 27, 2025にアクセス、 https://robertcelt95.medium.com/css-architecture-for-design-systems-from-bem-to-css-modules-to-utility-first-443a12303a01
36. CSS Architecture: From BEM to Tailwind to Tokens - Superflex.ai, 11月 27, 2025にアクセス、 https://www.superflex.ai/blog/css-architecture
37. Atomic Design Methodology, 11月 27, 2025にアクセス、 https://atomicdesign.bradfrost.com/chapter-2/
38. Should I look for alternatives to atomic design? : r/reactjs - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/reactjs/comments/1cxvzm5/should_i_look_for_alternatives_to_atomic_design/
39. Is Atomic Design really practical for big projects ?? : r/reactjs - Reddit, 11月 27, 2025にアクセス、 https://www.reddit.com/r/reactjs/comments/ujuxj2/is_atomic_design_really_practical_for_big_projects/
40. Reimagine Atomic CSS - Anthony Fu, 11月 27, 2025にアクセス、 https://antfu.me/posts/reimagine-atomic-css
41. Use tailwind within atomic design methodology - DEV Community, 11月 27, 2025にアクセス、 https://dev.to/zhangzewei/use-tailwind-within-atomic-design-methodology-1bi8
42. Atomic Design in React: Best Practices - Propelius Technologies, 11月 27, 2025にアクセス、 https://propelius.ai/blogs/atomic-design-in-react-best-practices
43. React Folder Structure in 5 Steps [2025] - Robin Wieruch, 11月 27, 2025にアクセス、 https://www.robinwieruch.de/react-folder-structure/
44. The evolution of scalable CSS, Part 6: Atomic CSS - Andrei Pfeiffer, 11月 27, 2025にアクセス、 https://andreipfeiffer.dev/blog/2022/scalable-css-evolution/part6-atomic-css