Koichiro Matsuoka

### Question > いつも参考にさせてもらっています。 > 集約に関する質問です。 > > 100個程度（可変）の値オブジェクトのコレクションを持つことが想定されるファーストクラスコレクションを作成しました。 > このクラスは不変表明を持ち、保たなければならない整合性を持ちます。 > コレクションの中身が置き換えられることでミューテーションが起こります。 > > 集約はトランザクション整合性を保つ単位で作成すると認識していた私は、このクラスを集約としてモデリングし、この単位でRepostory経由で永続化を行うようにしました。 > > しかし、Evans本の集約のところを読み返したところ、次のように書いてありました。 > > 「集約とは、関連するオブジェクトの集まりであり、データを変更するための単位として扱われる。各集約にはルートと境界がある。境界は集約の内部に何があるかを定義するものだ。ルートには集約に含まれている特定の1エンティティである。」 > > 先程集約としてモデリングしたファーストクラスコレクションにはルートとなるエンティティがないので、集約としてモデリングするのは不適切な気がしてきました。 > > このような場合、先程の不変表明を持つファーストクラスコレクションはどのようにモデリングするのが適当だと思いますでしょうか？ ### Answer...

### Question > いつも発信参考にしてます！ > Mailの実装に関する質問でよく松岡さんはEmailエンティティーを実装して、EmailSenderのIFを作ってインフラ層で実装するとおっしゃっているのですが、repositoryでもなく、エンティティーでもないEmailSenderというIFはどういう立ち位置なのでしょうか？ ### Answer それはシンプルに「メール送信するクライアント」を表すIFです。重要なことは、「ドメイン層にエンティティやリポジトリなどのDDDの実装パターン以外のものも定義して良い」ということです。

### Question > 引数オブジェクト(Parameter Object)とデータ変換オブジェクト(DTO)は同じものなのか、違うものなのかをうまく言葉にできず悩んでます。良い説明ありますでしょうか？ ### Answer 定義する人によって異なります。 大事なのは、そのクラスの責務(それは何を表す/何をするクラスなのか)を考えることです。引数オブジェクトは責務が明確ですね。特定のメソッドの引数を表すオブジェクトですね。名前もそのままで良さそうです。 では、データ転送オブジェクト(DataTransferObjectなので変換ではなく転送ですね)は何を表す、何をするオブジェクトでしょうか？おそらく、ここが曖昧ですね。転送とは何を表すのでしょう。これは、定義しないと定まらないのです。だからこそ、プロジェクトにおいてきちんと意味を定める必要があります。 例として、あくまで私が普段使用している定義では、オニオンアーキテクチャでユースケース層からプレゼンテーション層に値を受け渡すオブジェクトにDTOという名称をつけています。 https://gyazo.com/8232196108a851d6120f8fb09921bf27 (モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 「7章 ユースケース層の実装」より) これは一例なので、プロジェクトごとにきちんと定義をする、というのがとにかく大事なことです。

### Question > あるエンティティが集約A,Bに属する場合、そのエンティティは集約Aがあるパッケージか集約Bがあるパッケージのどちらに配置すればよいでしょうか？ ### Answer エンティティが複数集約にはあんまり属しくいので、どんなモデルかちょっと気になります、具体例追加質問もらえると嬉しいです。まずは一般論で回答します。 値オブジェクトは割と複数集約で使用することが多いです。わかりやすいのはIDを表すクラスです。 関連する回答が「DDDサンプルコード&FAQ」の8.6.2 節あります。 https://gyazo.com/3fab2b1aad7a486be02f18f869bdced5 もし他の回答も気になったらぜひお手に取ってみてください！ https://little-hands.booth.pm/items/3363104

### Question > インフラ層の実装時のクラス名のネーミングについて伺います。モデルにインターフェイスを作っているのでそちらのネーミングについても伺います。 > > 松岡さんはどのようなサフィックスをつけてますか？ > > メールを送信する。 > ファイルを作成して、会計システムに送信する。 > pdfを作ってweb strageに配置する。 > 他アプリケーションのAPIを呼び出し登録する。 > 他アプリケーションのAPIを呼び出し検索する。 ### Answer インターフェイスには「What」、実装クラスには「How」つまり「どんなライブラリを使って実現するか？を表すことが多いです。例えばjOOQというORMを使ったリポジトリでは、インターフェイスはXxxRepository、実装クラスはXxxJooqRepositoryといった具合です。 メールだったらSendGridというサービスを使っていたらMailSenderというIFに実装クラスはMailSendGridSenderと言った具合です。 これはいろんな案が考えられますので、一例として参考までに。

### Question > 先日のイベントで、「モデリングを行わないDDD」についても肯定的なご意見だったと思います。 > こういったいわゆる軽量DDDのユースケースは、どのようなパターンを想定されていますか？ > 個人的には複雑でないドメインに対しても十分効果を発揮するのではないかと思慮しています。 ### Answer ちょっと訂正すると、「モデリングを行わないDDDに肯定的」というより、「ものすごくシンプルな場合は実装前にモデリングが不要になる場合もある」ぐらいのニュアンスです。 ただ、「ものすごくシンプル」だと思っても後から追加で言語化されていなかった要件や知識が出ることは往々にしてあるので、基本的にはモデリングを軽くすることをお勧めします。モデリングを試みて、「あ、もう十分だね」となったらすぐ切り上げれば良いだけですからね。 DDDのアプローチをする前に目的は言語化しておくと良いと思います。DDD機能性と保守性を高めるのが目的で、機能性を高めるのが主にモデリング、保守性を高めるのが主にモデルをそのまま表現する実装パターンです。実装パターンだけ取り入れるのが軽量DDDと言われるものです。課題感が保守性であれば実装パターンだけ取り入れても効果があるよね、という位置付けで解釈できるといいと思います。

### Question > DDDと相性の良いローコード開発ツールは何があるか教えていただきたいです ### Answer DDDの中でもモデリングとコーディングの2つで大まかに分けられますが、モデリングは特にツールは選びません。ただ、コーディングはちょっとローコードとはあまり相性はよくないかもしれません。 「作成したドメインモデルを極力そのままの形でコードに落とす」というのがDDDのコーディングにおける戦略ですが、ローコードだと表現できることにかなり制約が出るため、あまりDDDのプラクティスは使いにくいと思います。ただ、モデリングに関しては要件を洗い出したりローコード上でどんなデータを定義するかと言ったインプットとして有効なので、そこは試みても良いと思います。 モデリングに関してはこちらの動画に具体例があるので参考にされてください。 https://www.youtube.com/watch?v=A2EU0paEVJ0

### Question > ドメインモデル(Value Object、Entity)のコンストラクタでバリデーションエラーを検出した時に送出する例外クラスは、ドメイン層にドメイン独自のユーザー定義例外として定義するべきなのでしょうか？ > > それともJavaのIllegalArgumentExceptionのような言語の組み込み例外を使ってもよいのでしょうか？ > > 状況による場合はそれぞれのメリット/デメリットを教えて頂けるとありがたいです。 ### Answer ドメイン層の独自例外を投げるのがおすすめです。例外処理についてはこちらに関連ツイートがあるのでご覧ください。 https://twitter.com/little_hand_s/status/1480317801084907522?s=20 もし他の回答も気になったらぜひお手に取ってみてください！ https://little-hands.booth.pm/items/3363104 (元質問：) ドメインモデル(Value Object、Entity)のコンストラクタでバリデーションエラーを検出した時に送出する例外クラスは、ドメイン層にドメイン独自のユーザー定義例外として定義するべきなのでしょうか？ それともJavaのIllegalArgumentExceptionのような言語の組み込み例外を使ってもよいのでしょうか？ 状況による場合はそれぞれのメリット/デメリットを教えて頂けるとありがたいです。

### Question > 櫻坂46の遠藤光莉ってご存じですか？神奈川県出身のアイドルで、2014年には「WORLD HIPHOP CHAMPIONSHIP 2014 in LAS VEGAS」 バーシティ部門で入賞するなどかなりの腕前です。 > ### Answer 初耳でした！ダンス上手な子なんですね！ 調査の結果、愛称がえんぴかちゃんだということを認識しました！笑

### Question > 21歳という若さでDDDに出会えて本当に良かったなと感じてますが、これは早い方でしょうか？普通の企業では教育で教わるものなのか などDDDの認知度を知りたいです。 > 大企業に務めているのですが、ソフトウェアに最近力を入れ始めた企業という事もあり、仕様書（UML）やコーディングのチェック、テストコードなどの環境が全く無く今は独学で補おうと頑張ってますが、転職後も周りに劣らないようにするには何を学ぶべきかアドバイス頂きたいです。 ### Answer DDD普及度合いは微妙で、「出会う」と言ってもその濃淡もあるので　早い遅いは何とも言えないですね。企業の新卒教育などのコンテンツになっているところは主観ですが少ないのではないでしょうか。 重要なのは出会う早さより深さです。僕は高校時代にC言語と出会いましたが現状全く書けません。笑　そのモチベーションは素晴らしいと思いますので、ぜひ手を動かして、より深いところまで理解を深めていきましょう! 学ぶべきことはまず「目の前のプロジェクトで役立てそうなこと」が一番です。業務の時間で実践できるのが何より学びとしては深くなります。現在の企業で環境が整っていないのであれば、そこに何を導入すると良いのか、というのを軸で学んで導入するのが一番いいと思います。転職時一番見られるのは「こういうのを学んでました」よりも「こういう課題に対してこういう活動をしました」という内容です。インプットより、アウトプット！それを心がけて学べるといいと思います。