104dev

ドメインモデル設計における「Entityを増やすかどうか」の判断整理

— 名詞・業務ルール・2×2で考える —

はじめに

DDDで設計していると、次のような判断に必ずぶつかります。

• 顧客・注文といった主要な概念は切り出せた
• しかし業務ルールを整理していくと、新しい概念が次々に現れる
• これは新しい Entity にすべきか？

104dev

アーキテクチャ選定とは何を決めているのか

〜ごちゃつきやすい設計概念を軸で整理する〜

本メモは、DDD・クリーンアーキテクチャ・トランザクションスクリプト・
Active Record・Service / Repository・MVC・レイヤードといった
混同されやすい概念群を整理するための設計メモです。

ここで扱うのは、
フレームワークや言語の選定ではなく、

104dev

クラスとは何か — 言語機能としてのクラスと設計との境界 —

〜クラス設計を考えるためのベースの話〜

本メモは、「クラスとは何か」を人に説明するための整理用メモです。
設計原則や設計パターンの是非ではなく、あくまで言語機能としてのクラスにフォーカスして説明します。

---

結論：クラスとは何か

104dev

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    root /srv/example.com/public;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    index index.php;