フォルダ名をEntityにしたら話し合いになったため、Entityについて考えてみます。
話し合いの内容は、「Entityという名前はModelでDBで使用する名前だ。普通のクラスに適用するのは違う」という内容でした。
私の主張は「名詞的な使い方でルール等が書かれたクラスとして使用している」という感じで、噛み合うことがない話し合いで終わりました。平行線になったため、Entityという名前は使用しないようにしましたが、考えるきっかけになりました。
Entityについて
ChatGptにEntityについてどういう意味合いで使用されますか？と質問してみます。
「エンティティ（Entity）」という言葉は、分野によってニュアンスが少し異なりますが、基本的には「独立して認識できる対象」という意味を持ちます。
| 分野 | エンティティの意味 | 例 |
|---|---|---|
| データベース | データとして管理する対象 | ユーザー、商品、予約 |
| DDD/オブジェクト指向 | IDで識別されるオブジェクト | User(id=1) |
| NLP | 固有名詞などの特定対象 | 山田太郎、東京都 |
| ゲーム/IoT | 独立した存在として扱うもの | プレイヤー、センサー |
分野によって意味合いが少し変わるみたいですね。
ちゃんと説明ができなかったこと
話し合いが平行線なったことについて考えることがありますが、説明がちゃんと出来ていないため相手に納得してもらうことができなかったと思います。事前知識の影響もありますが、ドメイン駆動開発の知識のあるないは大きいと思うようになりました。
ドメイン駆動の勉強し始めの時に、Entityの捉え方が難しかったことを思い出しましたが、「Entity == DBのモデル」でないことがしっくりきませんでしたね。
相手はER図(Entity-Relation図)を根拠に示し、EntityはDBのモデルである。という主張から変わらず、フレームワークによってはEntityというクラス名がModelの値になることを説明しました。
ER図がDBの表現で使用されることが多いため理解はできますが、EntityがDBである必要はないわけです。ファイルで管理されていてもデータが保存取得できれば問題ないというわけです。DBが便利なツールとして使用されているだけだと思っています。
モデルEntityとドメインEntityの違いを説明できなかったことも問題だったと反省しました。
説明することで理解度が足りないことが把握できるため、人に教える機会や説明する機会がある環境が作れるといいですね。
自分は話し合いが平行線になったことに凹んで一時的に自分の作業だけに集中するようになった気がします。あとで別の人にEntityについて話してみたところ、自分と近い認識で救われましたね。
