Zenn
🔥

設計のタイトルについて

に公開
CSS設計
tech

とても良い視点です！
実際、「設計」という大カテゴリの中に 「システム設計」と「DDD」 をどう位置づけるかは、
そのブログやナレッジの**目的（誰に何を伝えるか）**によって少し変わります。

🧠 まず考えるべき軸：設計の分類

分類カテゴリ 説明 例
システム設計（System Design） アーキテクチャ、構成、スケーラビリティ、可用性 マイクロサービス構成、サーバレス設計、DB分割
ソフトウェア設計（Software Design） アプリケーション内部の構造やパターン MVC、レイヤードアーキテクチャ、OOP
ドメイン設計（DDDなど） ビジネスロジックに注目した設計 エンティティ/バリュー/ユビキタス言語、集約設計
UI設計 / UX設計 ユーザーインターフェースと体験設計 情報設計、ナビゲーション、ユーザーフロー

✅ あなたのケース：DDDとシステム設計を分けるなら？

これは正解です。DDDはシステム設計の中でもかなりビジネスロジックに寄った設計であり、
「システム全体構成」とは粒度も対象も違います。

🏷️ カテゴリ名のおすすめ（シンプル＆目的に沿ったもの）

内容 カテゴリ名の例 備考
サーバー構成やインフラ含む広義の設計 システム設計 / アーキテクチャ設計 負荷分散やDB分離の話など
コード構造やドメインモデリング ドメイン設計 / DDD / 業務ロジック設計 DDD、OOP設計原則など含む
全体を包括する上位カテゴリ 設計全般 / 設計ノート / 設計思考 他カテゴリの親カテゴリになる場合に使う

🎯 たとえばこんな階層構造もアリ：

設計
├─ システム設計
│   └─ サーバレス構成とは
│   └─ マイクロサービス分割
├─ ドメイン設計（DDD）
│   └─ DDDの4層アーキテクチャ
│   └─ ユビキタス言語とは？

✍️ 結論：あなたの状況なら

  • ✅ 設計：親カテゴリ
  • ✅ システム設計：構成やアーキテクチャ関連
  • ✅ ドメイン設計 or DDD：ビジネスロジックに関する構造や考え方

このように切り分けるのが、読者にも明快で管理もしやすくなります。

必要なら、カテゴリ名だけでなく、タグ戦略（「レイヤード」「CQRS」など）も一緒に考えられますよ。興味ありますか？

システム設計とドメイン設計ですか？OOPなどもドメイン設計に入る、と考えると、ドメイン設計はレベルが低すぎる気がします。他の名前はありますか？

とても良い視点です。
おっしゃる通り、**「ドメイン設計」**という名前に OOPやレイヤードアーキテクチャなどを含めてしまうとスコープが狭く見えすぎる んですよね。

🧠 あなたが扱いたい範囲（例）

  • OOP（SOLID原則など）
  • DDD（エンティティ・バリュー・集約）
  • アーキテクチャ（MVC / レイヤード / クリーン）
  • 責務分離、データ構造、抽象化の戦略

これらを包含するカテゴリ名としては、「ドメイン設計」では不足です。

✅ より適切なカテゴリ名候補（思想・技術の幅を保ちつつ）

候補 ニュアンス・含まれる内容
アプリケーション設計 コードレベルの構造、責務、OOP、アーキテクチャ含む
ソフトウェア設計 言語やドメインを問わず汎用的。OOP〜DDDまで含められる
内部設計（or 内部構造） 外部設計（システム設計）との対比。現場用語より
構造設計 アーキテクチャ・レイヤー構造などを中心に扱う意図
実装設計 実際のコード構造を対象にしていることを強調（やや低レイヤー感あり）

🎯 おすすめ：「ソフトウェア設計」

理由：

  • 「システム設計」とペアで並べたときにバランスがよい（外部設計 vs 内部設計的な対比）
  • OOP、設計原則、アーキテクチャ、DDDまで幅広く含められる
  • スコープが広すぎず、でも狭くもない（業務ロジックだけに限定されない）

🔖 例：カテゴリ構成案

設計
├─ システム設計（インフラ、構成、スケーラビリティ）
├─ ソフトウェア設計（OOP、アーキテクチャ、DDDなど）

✅ まとめ

  • 「ドメイン設計」だと狭すぎる（DDDに寄りすぎ）
  • 「ソフトウェア設計」や「アプリケーション設計」の方が、OOP・設計原則・構造を含めやすい
  • 「設計」カテゴリの中でバランスを取りたいなら「システム設計 / ソフトウェア設計」の2軸がベスト

もしZennなどでカテゴリを整理したいなら、記事例を元にネーミング案も一緒に整備できますよ！整理したい構成がありますか？

Discussion