Koichiro Matsuoka

### Question > モデリングをしっかりと行えればテーブルの正規化は必然と出来るのでしょうか？もしくはモデリングの後にテーブルの正規化は別で行うのでしょうか？ ### Answer 別です。 ドメインモデルのモデリング(ドメイン層の設計)を行い、それを永続化するためにはどういうテーブルが良いかというテーブル設計(インフラ層の設計)を行います。その場合、永続化したり参照するにあたって正規化するべきかどうかはインフラ層の関心ごととしてインフラ層の中で最適化する、という考え方をします。

### Question > CleanArchitectureでrepositoryのインターフェースからentityへはuse case→entityなので参照できると思うんですが、repositoryの実装からentityへは参照できないことになりますか？(できるほうが自然だと思ってますが) > もしくは隣接していなくても外から内への参照は可能とういルール？ ### Answer リポジトリのインターフェイスとしてエンティティを渡すメソッドを定義するので、それを実装するクラスのメソッドにもエンティティが渡されることになります。 渡されるのに使ってはいけないというのはおかしいので、そのまま参照して実装を進めて良いと思います。 レイヤー化に関しては緩いレイヤー化と厳しいレイヤー化というものがあるので、こちらの記事を参考にしてみてください。 https://little-hand-s.notion.site/DDD-Note-e51d9f6497ef43e2804ff65dcc007ed1

### Question > ドメイン駆動設計のメリット、デメリット、 > どのようなものを作るときに向いていて、 > どのようなものを作るときに向いていないのか > 教えていただきたいです。 ### Answer メリット、というより目的は、①機能性を高める＝役立つものを作ること②保守性を高める=技術的負債の量を増やさずに開発し続けることです。デメリットとしては、導入において知識のハードルがあること、推奨するアーキテクチャの実装オーバーヘッドがあることです。 向き不向きとしては、ソフトウェアが使われる領域(ドメイン)が複雑なときに向いていて、シンプルすぎるもの、複雑さの中核がドメインではなく技術的なもの(大量高速処理、機械学習など)にはあまり向いていないです。 DDDの狙いについては以下の動画で解説しているのでよろしければご覧ください。 https://www.youtube.com/watch?v=A2EU0paEVJ0

### Question > DDDにおいてレポジトリをSingletonにすることは推奨されていますか？Singletonにすることのデメリットも教えて頂きたいです。 ### Answer とくにDDDでは言及されていません。シングルトンにすること自体は特に問題ないと思います。

### Question > 集約に関して質問させていただきます！ > 集約間で参照してよいのは集約ルートのIDのみでしょうか？ > 集約の子エンティティを他の集約から参照したくなった場合には、その子エンティティを別集約にするという方針になりますか？ > 初歩的な質問で失礼いたします。よろしくお願いします！ ### Answer あってます！集約はリポジトリから出し入れする単位なので、インスタンス山椒を許すと別集約のものもリポジトリから取れてしまうようになります。 なんでこんなことをするかというと、集約を跨いだオブジェクト間の依存性を下げてコードの保守性を上げるためです。

### Question > valueオブジェクトについて2点質問です。 > 1.基本的に、エンティティが持つフィールドとなるものは、業務上意味のある単位である可能性が高いためvalueオブジェクトにしておいた方が良いのかなと思っていますが如何でしょうか。 > 2.ユースケース層がエンティティ内部のvalueオブジェクトの関数を呼び出したい時、直接entity.value.hogehoge()とすると抽象度が下がってしまうような気がします。この場合、entityに間を取り持つ関数を用意するべきでしょうか。 ### Answer 1.必ずしもそうとは言い切れません。メリットデメリットを考慮して判断しましょう。値オブジェクトをくくり出すメリットは、ドメインの知識が対応するクラスで表現できて高凝集・低結合になること、タイプセーフになることです。 小さなデメリットとはクラスが増えることで、多少ならば基本的に問題ありませんが、クラス数が10個とかになってくると流石にクラス数、ファイル数の増加でコードが追いにくくなります。 このバランスを考えると、表現する知識がないのに常に値オブジェクトにする、という必要はなく、そのオブジェクトに詰め込みたい知識がある場合に値オブジェクトをくくりだす、ぐらいの考え方が良いと思います。 2は、値に取り持つ関数を持った時にその関数の責務が明確か、可読性が高まるか、という判断基準で考えましょう。 例えばUserクラスがMailAddress値オブジェクトを内包しており、MailAddress.isValidFormat()というメソッドがあったとします。これをラップしてUser.isEmailAddressValidFormat()というメソッドを持ったとして、このメソッドの責務は何でしょうか？例えば「ユーザーは有効なメールアドレスを持っていれば有効ユーザーである」といった判断に使うのであればいいかもしれません。ただし、その場合は「User.isValidUser」といった責務にあったメソッド名にした方が良いでしょう。そのようなUserクラスが表現する知識がなく、ただ内部メソッドを呼ばせたくないだけの場合、もしかすると責務が不明瞭なメソッドになってしまうかもしれません。その場合はEmailAddressクラスを返して直接メソッドを呼ばせるという選択肢もありだと思います。

### Question > DTOについて質問です。DTOはEntity(およびValueObject)をアプリケーション(ユースケース)層からプレゼンテーション層に変更されないデータを渡すためのものという認識なのですが、合っていますか？また、インフラ層(を通してDB)にデータを渡す際にもDTOを使用しても良いのでしょうか？ ### Answer DTOに関してはDDDで定義されているわけではないので、それはプロジェクトで定義する内容です。私はご質問にあるものをDTOと呼ぶようにしています。インフラ層にデータを渡すものは、DTOと読んでも良いですし、使い分けのために別の名前に名前にしても良いと思います。大事なのはその認識がプロジェクトで統一されることです。

### Question > 高凝集の説明ツイートにあるクラスの責務って何でしょうか？ > クラス間の関連端のことでしょうか？ > > ### Answer 「そのクラスは何をする(何を表す)クラスか？」と考えた時の答えがそのクラスの責務です。

### Question > ぬるぽ ### Answer 世代がバレちゃうぞ！

### Question > エンティティやバリューオブジェクトについては書く時悩むことはあまりないのですが、複数のエンティティが絡む処理をドメインサービスとして記述していると、アプリケーションサービスとの境が曖昧になることがあります。（今やろうとしていることは、重要なビジネスロジックだから、ドメイン？　それとも機能を調整しているに過ぎずアプリケーション？　のような） > 基準のようなものはありますでしょうか？ > > ### Answer 似た質問があったので、こちらの回答をご覧ください！ https://github.com/little-hands/ddd-q-and-a/issues/745