第35章：プロジェクト構成A（まず置き場所）🏗️
この章のゴール🎯
- Bounded Context（BC）ごとに「置き場所」を分けて、混ざらない土台を作れる🏠✨
- モジュラーモノリス（＝ひとつにデプロイできるけど、中は境界で守る）で始められる🧱💡
- 後の章（参照ルール・DTO/ACL）を安全に積める形にしておく🚀
1) 置き場所を分けると、何が嬉しいの？🧠💖
BCを分けるって、イメージは 「言葉（用語）とモデル（ルール）の世界が違う」 を守ることでしたよね🗺️✨ でもコードは放っておくと、すぐこうなりがち👇😵💫
Customerが 会員でも 請求先でも 配送先でも使われるOrderStatusが部署ごとに意味がズレてるのに、同じ enum に押し込む- 便利だから
Commonに全部入れて、結局 “全部つながる” 地獄😇🔥
なので最初にやるべきはこれ👇
✅ 「BCごとに住所を分ける」（プロジェクト/フォルダ/名前空間）🏠🏠🏠 ✅ 境界を越えるときは “玄関” を通る（契約DTOやACLは後の章で）🚪📨
2) 2026の“安定スタック”を選ぶコツ🧩🔧
いまの安定ラインとしては .NET 10（LTS） が軸にしやすいです✅ リリース日やサポート期限が公式表で管理されていて、2028-11-14 までサポートが続きます📅🔒 (Microsoft) C#も C# 14 世代が前提になり、拡張メンバーなど新しい構文が入っています🧠✨ (Microsoft Learn)
IDE側も Visual Studio 2026 のリリースノートが出ています🛠️✨ (Microsoft Learn)
3) まずは「モジュラーモノリス」でOK👌🧱
いきなりマイクロサービスにすると、境界は守れても…
- デプロイ、認証、監視、通信、データ整合性…やること爆増💣😵💫
- 学習としては「境界の本質」より「運用の大変さ」が先に来ちゃう
なのでこの章では、こうします👇
✅ 1つのソリューションで、BCごとにプロジェクトを分ける ✅ デプロイは1つ（Web/APIホスト） ✅ 境界は参照ルールと公開契約で守る（次章以降）
4) “おすすめの置き場所”テンプレ🗂️✨（ミニEC例）
ミニEC（受注・在庫・配送・請求）を例に、こんな形が扱いやすいです👇🛒📦🚚💳
MiniECommerce.sln
└─ src
├─ AppHost
│ └─ MiniECommerce.AppHost （起動プロジェクト：Web/APIなど）
│
├─ Modules
│ ├─ OrderManagement
│ │ ├─ MiniECommerce.OrderManagement （まずは1プロジェクトでもOK）
│ │ └─ MiniECommerce.OrderManagement.Contracts（外に見せるDTO置き場案）
│ ├─ Inventory
│ │ ├─ MiniECommerce.Inventory
│ │ └─ MiniECommerce.Inventory.Contracts
│ ├─ Shipping
│ │ ├─ MiniECommerce.Shipping
│ │ └─ MiniECommerce.Shipping.Contracts
│ └─ Billing
│ ├─ MiniECommerce.Billing
│ └─ MiniECommerce.Billing.Contracts
│
└─ BuildingBlocks
└─ MiniECommerce.BuildingBlocks （技術寄り共通：ログ/結果型など）
ポイント🌟
- Modules/ の下に BCごとの島を作る🏝️✨
Contractsは 「外に出す言葉（Published Language）」 の候補置き場📨📢（本格運用は第34章〜）BuildingBlocksは “業務じゃない共通” のみ（増やしすぎ注意⚠️）
5) Visual Studioで作る手順（気持ちよく迷わない版）🧭✨
5-1. ソリューション作成🧱
- 新しいプロジェクトの作成
ASP.NET Core Web API（またはConsoleでもOK）- 名前を
MiniECommerce.AppHostにする - ソリューション名を
MiniECommerceにする
5-2. “Modules” 用のフォルダを作る📁
ソリューションエクスプローラーで👇
-
ソリューションを右クリック → 追加 → 新しいソリューション フォルダー
srcModulesBuildingBlocks
（※ソリューションフォルダーは “見た目の整理” なので、物理フォルダも揃えるなら後で移動してOK👌）
5-3. BCプロジェクトを追加🏝️
例：OrderManagement を作るなら👇
Modulesの下にソリューションフォルダーOrderManagement- その中に
Class Libraryを追加 →MiniECommerce.OrderManagement
同様に Inventory / Shipping / Billing も作る✨
6) dotnet CLIで一気に作る（再現性MAX）⚡🧪
GUIが苦手な人や、AIに手順を渡したいときは CLI が強いです💪✨
mkdir MiniECommerce
cd MiniECommerce
dotnet new sln -n MiniECommerce
mkdir src\AppHost
dotnet new webapi -n MiniECommerce.AppHost -o src\AppHost\MiniECommerce.AppHost
dotnet sln add src\AppHost\MiniECommerce.AppHost\MiniECommerce.AppHost.csproj
mkdir src\Modules\OrderManagement
dotnet new classlib -n MiniECommerce.OrderManagement -o src\Modules\OrderManagement\MiniECommerce.OrderManagement
dotnet sln add src\Modules\OrderManagement\MiniECommerce.OrderManagement\MiniECommerce.OrderManagement.csproj
mkdir src\Modules\Inventory
dotnet new classlib -n MiniECommerce.Inventory -o src\Modules\Inventory\MiniECommerce.Inventory
dotnet sln add src\Modules\Inventory\MiniECommerce.Inventory\MiniECommerce.Inventory.csproj
（Shipping/Billing も同じ要領で増やすだけ🧩✨）
7) 命名ルール（置き場所の“迷子”を防ぐ）🏷️🧠
✅ 良い名前の条件
- BC名が入ってる（どの島か一発で分かる）🏝️
- 役割が想像できる（Host / Contracts / Domain…）🔍
- 短すぎない（
Orderみたいな曖昧語は衝突しやすい）💥
例（わかりやすい系）✨
MiniECommerce.AppHostMiniECommerce.OrderManagementMiniECommerce.OrderManagement.Contracts
8) “共通”の置き場所、3つの安全ライン🧯⚠️
8-1. まず最強：外部ライブラリに寄せる📦✨
ログやDIなどは、できるだけ 既存の仕組みを使うのが事故りにくいです👍
8-2. BuildingBlocks（技術寄り共通）🧱
OKになりやすい例👇
Result<T>（成功/失敗を統一する型）- 例外の共通ポリシー
- 技術的な小物（時刻プロバイダのIFなど）
NGになりやすい例👇😇
CustomerやOrderを共通に置く（＝意味が混ざる💥）- “便利ユーティリティ” が巨大化する（全部が依存する👻）
8-3. Shared Kernel（業務共通）は最後の最後🥺
「本当に同じ意味で共有できる」と証明できたときだけ💡 （証明できないなら “契約DTO” で渡すほうが安全📨）
9) 最小の“島”を1つ作って動かしてみよう🏝️💻
OrderManagement に、超ミニでいいので ドメインっぽいルールを置いてみます✨ （この章は “置き場所” が主役なので、内容は薄くてOK👌）
namespace MiniECommerce.OrderManagement;
public readonly record struct OrderId(Guid Value)
{
public static OrderId New() => new(Guid.NewGuid());
}
public sealed class Order
{
public OrderId Id { get; } = OrderId.New();
public DateTime CreatedAtUtc { get; } = DateTime.UtcNow;
// ここに「受注管理としてのルール」が育っていくイメージ🌱
}
✅ これで「受注の世界の言葉」は MiniECommerce.OrderManagement に隔離されました🏠✨
10) AI拡張の使いどころ（この章は“骨組み生成”が強い）🤖⚡
Visual Studioの GitHub Copilot を使うコツ💡
- Copilot の状態管理やインストール手順は公式で案内されています🧩 (Microsoft Learn)
- 環境設定（Tools → Options → GitHub → Copilot…）の導線も、GitHub側ドキュメントにあります📘 (GitHub Docs)
- Visual Studio 2026 のリリースノートにも Copilot 関連の機能案内が載っています🛠️ (Microsoft Learn)
便利プロンプト例🪄（コピペOK）
- 「ミニECのBounded Contextを OrderManagement / Inventory / Shipping / Billing に分けて、.NETのソリューション構成（AppHost + Modules + BuildingBlocks）を作る手順を、dotnet CLIコマンドで出して」
- 「各モジュールに
Contractsプロジェクトも作って、DTOはモジュール外にドメイン型を漏らさない方針で雛形を作って」 - 「
BuildingBlocksに入れて良いもの/ダメなものを、具体例付きでチェックして」
11) ミニ演習🧩🎮
演習A：島を4つ作る🏝️🏝️🏝️🏝️
OrderManagement / Inventory / Shipping / Billingの4プロジェクトを追加- それぞれに
namespaceが混ざってないか確認（例：OrderManagementの中にInventoryが出てきたらアウト🙅♀️）
演習B：Contracts を追加して「玄関」を作る🚪📨
MiniECommerce.OrderManagement.Contractsを追加- そこに
OrderSummaryDtoを置く（中身は空でもOK） - “ドメイン型を置かない” を守る（
Orderクラスは置かない🙅♀️）
12) よくあるつまずきポイント集😵💫🧯
❌ Common を作って何でも入れる
➡️ 境界を壊す最短ルート💥 “便利” は後からでも作れるけど、壊れた境界は戻すのが大変😭
❌ BC名が曖昧すぎる
➡️ Order / User みたいな単語は衝突しやすい⚡
“何を管理するBCか” まで名前に出すと事故が減ります🏷️✨
❌ 物理フォルダとソリューション表示がバラバラ
➡️ 後で直せるけど、最初から揃えると気持ちいい📁✨ （CIやレビューで迷子が減る💖）
13) この章のチェックリスト✅✅✅
-
src/AppHostとsrc/Modulesが分かれている - Modules は BCごとにプロジェクトがある
- “業務共通” を安易に作ってない（特に
CustomerやOrder） - 境界を越えるための
Contracts（玄関）を置ける構造になっている - 依存関係を固定できる余地がある（次章でやるよ📐）
お助けAIプロンプト（第35章）🤖✨
- 「このソリューション構成、境界を壊しそうな“共通化”ポイントを指摘して」🔍
- 「4つのBCに分けたプロジェクト名を、衝突しにくい命名に直して案を3つ」🏷️
- 「Contracts に置くDTO案を、ドメイン型を漏らさないルールで提案して」📨
- 「BuildingBlocks に置いて良い型/悪い型を、具体例付きで分類して」🧱⚠️