Koichiro Matsuoka

### Question > 外部APIを利用するようなアプリケーションを考えます。 > その外部APIの仕様に合わせてそこそこなロジックが必要な場合があります。 > その場合、外部APIを利用する層(インフラ層)にて新たなドメイン層をネストして構成したくなります。 > このような場合のベストプラクティスはどうなりますでしょうか？ ### Answer 外部APIの戻り値のクラスと、そのリクエストをするクライアントのIFはドメイン層、実際の呼び出し処理はインフラ層に書きましょう。 「呼び出し方」を隠蔽すm、外部サービスから何を返されるかを抽象的なクラスで表現できれば、それはドメイン層のモデルとしても問題ありません。

### Question > 学校の図書室で使われるような書籍管理アプリを作成しています。 > ドメインオブジェクトとしてUser、Bookを作成し、それぞれのフィールドに書籍の貸し出し情報を表すLendInfoオブジェクトを持たせたいです。(Userの現在の貸出情報、書籍のこれまでの貸出情報) > 一方で、LendInfoオブジェクトにもUser、Bookのフィールドを持たせたいです。 > 双方向でフィールドを持ってしまうと、repositoryとのやり取りに困ります。 > どのようにするのが良いでしょうか。 ### Answer まさしく、そう言う問題を解決するために「集約」があります。参照ルールは、「集約内はインスタンス参照、集約跨ぎはID参照」です。ご質問の場合も後者になると思います。 集約はリポジトリから出し入れする単位なので、集約を跨いでインスタンス参照するとリポジトリから他の集約のオブジェクトが取れてしまうことになります。これを上記の方針にすると、リポジトリがオンメモリのリストのような、シンプルなオブジェクトの集合として扱えるようになります。

### Question > こんにちは本を読まさせていただきました。 > そこで質問なのですが、 > dddは簡単に言うとお片づけと同じ感じでしょうか？ > おもちゃはおもちゃ箱に > 服は衣装ケースに > 食料は冷蔵庫に > みたいな形で保管する場所を用途に応じて配置する。 > それがプログラムの場合はユースケースやドメインに分かれているみたいなところからスタートで大丈夫ですかね？ ### Answer 簡単に言うと「機能性と保守性の両方を高める手法」ですね。そのためのモデリングと実装パターンがある，と言う感じです。ぜひ進め方はDDD FAQを読んでみてください！

### Question > いつも大変勉強させていただいてます！ドメインモデル図の作成に関してなのですが、値オブジェクトに関しても記載すべきでしょうか？ ### Answer まずはモデル図作成にあたって必要なルール/制約を書き出すことにフォーカスしましょう！その上で実装上値オブジェクトになるかは、集約設計時，実装時のタイミングで考えましょう。

### Question > ユースケースとドメインサービスの違いが曖昧です。ドメインサービスは複数のエンティティに跨るドメイン知識を持つ認識ですが、ユースケースも究極同様な気がします…！ ### Answer まず、実装しようとしている知識がドメイン層の知識かユースケースの知識か、という観点で切り分けましょう。整理に関しては、こちらの記事をご覧ください。 https://little-hands.hatenablog.com/entry/2019/07/26/domain-knowledge ドメイン層の知識は、「ユースケース層によって異なってはいけない」ものです。ユースケースの実装は、「ユースケースによっては変わることもある」ものです。 例えばメールアドレスの重複チェックをユースケース層の責務として実装した場合、「重複を許容するユースケースが現れても良い」と言うことになってしまいます。

### Question > あの、ご相談したいことがあり匿名で相談させていただければと思います。 > 相談したい内容は「私はどうすればよかったのか？」といった話です。 > > 私はとある開発チームに所属していまして、新しい人がチームに参加されました。（結構すごい人だと言う噂でした） > そこで、ことあるごとに「くそコードが！」と連呼されるようになりまして、チームの雰囲気も悪くなりその方が入ってから2名ほど転職してチームから抜けることになりました。 > > 私も立場が強くなく、発言権のある立場ではないので正直なところこの度転職をすることになりました。 > といいますか、コミットする度にくそコードと言われるのが嫌になり、逃げるように転職する形となりました。 > > コードの保守性や変更をしやすくするためにもコードをより良くしていこうとすることは悪いことではないのですが、いろんな人がいるなか開発しているなかで「クソコードだ！」や「クソコードを書くぐらいならさっさとやめれば！」といった最近話題のハラスメントすれすれの行動をするのはさすがに耐えれませんでした。 > > 今後、このような人の書いたコードにたいして「クソコードのレッテルを張って、職場に居づらくするようなタイプ」が増えてくると思っています。 > こういったタイプからは逃げ続けるしかないのでしょうか？ > ご教示頂けますと幸いです。 > > またいい動画教材がありましたらご紹介いただけますと幸いです。 ###...

### Question > 質問にすぐに答えていただきありがとうございます！ > 一番単純なモデリングについて質問した者です。 > 「松岡さんにとって一番単純なモデリングとはどのようなものでしょうか？」という質問に対して「まずは具体例をひたすら出していくことが大事だと思います。」という抽象的な答えをいただいたので混乱しています。 > 身近な例で良いので、松岡さんが考える一番単純な具体例を聞きたいです！ ### Answer ちょっと単純さを答える意義があまり汲み取れず、欲しい答えになっているかわかりませんが、単純なのは、登場するオブジェクト数がすくないものですかね？これで欲しいお答えになるかどうか。。m(_ _)m

### Question > モノリスを分解したいのですが、境界を探す方法についてご存知でしたら教えていただきたいです。 > 単一の機能のモデリングなどは様々な本に書かれているのですが、既存のシステムを分析する方法がわからないため悩んでいます。 > ユーザーのロール（利用者/管理者）による境界はわかりやすいのですが、いろんな機能があるので、どこで境界を引くべきか判断する良い考え方などあれば教えてください。 ### Answer マイクロサービス文脈では、DDDの境界づけられたコンテキストの単位で切るのが良いのでは、というのが選択肢として挙げられます。境界づけられたコンテキストの概念については次の記事をご覧ください。 https://little-hands.hatenablog.com/entry/2017/11/28/bouded-context-concept この記事にあるように、同じ「商品」というものを明らかに別のものを想起して使われている場合があればコンテキストが違う場合があります。その使われている範囲を整理して記事のように分離してあげると、そこがアプリケーションを切り分ける一つの選択肢として使える可能性があります。

### Question > 先日のイベントの中で「なかなかモデリングが浸透しない」と言っていたと思います。 > ただ、松岡さんが求めているモデリングが非常に高度なものをイメージしているようにも感じました。 > そこで質問ですが、松岡さんにとって一番単純なモデリングとはどのようなものでしょうか？ ### Answer まずニュアンスの訂正ですが、なかなかモデリングが浸透しないというより、やっていく中で徐々に手応えを掴んで浸透していくものなので気長にやりましょう、というニュアンスです。 単純かどうかというより、難易度の低い、手をつけやすいのはどういうものか、と読み替えてもよいでしょうか？ まずは具体例をひたすら出していくことが大事だと思います。抽象化はスキルが必要ですが、具体的にどういうものがあるか、というのはブレスト的にどんどん出していきやすいです。そこから始めて、抽象化して、集約の設計して、とできると後はコードに落とせるようになります。

### Question > いつも参考にさせて頂いております！ > > 元々rest apiで色々作れていたのですが、read要件が複雑になってしまい、readに特化したqueryを作っていこうと思っているのですが、エンドポイントの管理をどうするかで悩んでおりまして、、 > > readに特化したエンドポイントをどう定義、管理してありますか？ > read modelをエンドポイントに出すというのも考えてみてはいるのですが、参考にご意見伺いたいです！ ### Answer 一つの案としては、クエリ用のモデルを作るにしてもselectの軸になるテーブルがあると思うので、それを起点に名前をつけてしまうとかどうでしょう。 usersテーブルに他のテーブルをleft joinした場合、それは軸がuserなのでエンドポイント的にはuserを元にした名前にする形です。