https://zenn.dev/monarisa_masa/articles/5fa1522a258add

こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。

InnoScouterでは、Ruby製WebフレームワークであるHanamiを採用しており、DDDを用いて開発しています。 Hanamiについて言うと、私個人としては、前職も含めて4年ほど運用経験があります。

ここでは、Hanamiが出てくるとよく話題にされるRailsとの比較は取り扱いませんが、初めてHanamiについての記事を読まれる方にも分かるようなサンプルコードで説明したいと思います。

突然ですが、こちらが本日のメイントピックです。

今回は、「RubyでDDDやるならHanami」と言われてますが、本当にそうなの？ってところを掘り下げていきたいと思います。 ツイートが意味していることと、それに対する自分の考えを話していけたらと思います。

この記事の対象読者

• Rubyを触っていて、DDDをやりたいと思っている方
• Rubyを触っていて、ドメインロジックと永続化の責務分離に悩まれている方
• Hanamiを触ってみたけど、ドメインモデル貧血症になってしまった方

ドメインモデル貧血症の説明はこちらの記事がとてもわかりやすかったので、是非ご覧になられるとよいかと。

持ち帰ってほしいこと

そもそもHanami自体、レイヤリングについてはクリーンアーキテクチャをベースとしたディレクトリ構成を機能として提供してくれているため、DDDを取り入れやすい形になっていると言えます。 ただ一歩間違えると、①リポジトリとエンティティの責務が混ざってしまったり、②ドメインモデル貧血症に陥ってしまうという問題が起きてしまいます。 本記事ではそういった罠に焦点を当ててつつ、回避方法まで話します。

• リポジトリとエンティティの責務を知る。
• リポジトリとエンティティが混ざると何が悪いかを知る。
• (Hanamiの公式通りに)実装していると、リポジトリとエンティティの責務が混ざる。
• (Hanamiの公式通りに)実装していると、ドメインモデル貧血症が起きる。
• それらの回避方法

リポジトリとエンティティの責務を知る。