(DB)の2019年4月の問1をお題としたドメイン駆動設計チャレンジです。前回は、大きな登場人物は出てきました。エントリ枠はだいぶ形になってきましたが、さて。あと、開発者、専門家の言動が怪しくなってきました・・・エントリ枠を・・・どう使うの?専門家:さて、エントリ枠、だいぶ形になってきましたね。エントリ枠をどうするかというのがこのままだと?ですね。開発者:エントリ枠としては、業務ルールとしては、参加申し込みだったり、抽選だったりとかできますが、そもそものエントリ枠自体を探してきたり、作成したりするものって必要ですね。エントリ枠自体は、大会番号、種目コードから、該当するエントリ枠を持ってきたりするかと思います。エントリ枠を持ってくるというのは、業務ルールとはなんだかそぐわない気がします。開発者:はい、そこで、サービスという概念を取り入れることにします。ドメインの知識ではないけれど、ドメインの知識を実行するためだけにあるものと考えてもらえれば。専門家:ドメインの知識?ドメインというと、領地とか、領域とか、範囲っていう意味ですよね。開発者:はい、ここでいうドメインは、うーん、範囲の意味に近いかと。解決したい範囲、今回の場合は、大会への参加申し込みを受け付けるエントリサービスですね。大会に関する告知サービスとか、記録計測サービスは、これも解決したい範囲になるかと思いますが。専門家:ふむ、今回はエントリサービスが主題なので、エントリサービスの範囲についての業務ルール、えーと、参加申し込みだったり、抽選だったりをコンピュータシステムで解決したい、ですね。開発者:参加申し込みだったり、抽選だったりはエントリ枠であるのですが、コンピュータシステムで解決するためには、エントリ枠を生成したり、データベースに格納したり、検索したりする必要があったりします。専門家:うーん違いますね。あ、なので、サービスという概念が必要なのですね。専門家:エントリ枠はエントリ枠番号で特定したいです。あと、大会番号がわかれば、その大会のエントリ枠を全部持ってきて、大会のエントリ枠を全部持ってきたいです。開発者:これもドメインサービスと同じように、ファクトリという概念を導入します。yodai.qrunch.ioソフトウェア開発に関する技術や読書メモのブログです。Qrunch.netサーバー提供フィードバックを送信する。