はじめに

現在携わっているプロダクトで DDD を曲がりなりにも実践しているのですが、SaaS との連携で頭を悩ませてきました。

利用 SaaS は多岐に渡るのですが、特に悩んでいた、今も悩んでいるのが「顧客管理サービス（CRM）」です。問題となるユースケースは、CRM 側の顧客情報を自社システムに取り込むケースや逆に CRM に反映するケース、CRM と自社システムが交互にやり取りするような複雑なワークフローになります。

私の理解であれば自社システムと CRM でドメインがコンテキストマッピング出来そうというのがきな臭いポイントだと考えています。

それらのケースを設計・実装するにあたって次の課題を感じていました。

SaaS が絡むロジックはどこで、どこまで書いたほうが良いのか？

今回は、上述の課題を解消するための考察とアプローチを備忘します。実際のユースケースを取り扱わないので、抽象的な内容になります。また、そもそも DDD に則っていない、課題がズレているなどあるかもしれませんがご容赦ください。

前提条件

• 戦術的 DDD
• オニオンアーキテクチャ
  • 外部のサービスとのやり取りを担うインフラ層を設けている
• マイクロサービス

内容

現状次の考察に至っています。

• SaaS が絡むロジックを闇雲にインフラ層に閉じ込めない方が良い
  • そもそもロジックはドメインに書くべきですが、当初はそこにロジックがあると認識できていなかった… 💦
  • SaaS は「社外のサービス」という安直な認識から、自プロダクトのドメインと切り離したいと考え、インフラ層で臭いものに蓋をしていた
    • どんどん押し込めた結果、ロジックが集積していた
• SaaS と自プロダクトのドメインがコンテキストマッピング可能であれば、積極的に SaaS 起因であっても自プロダクトのドメインとしてモデリングした方が良い
  • そもそも設計の段階でドメインを上手くモデリングできていないだけ… 💦

よって、「SaaS が絡むロジックはどこに、どこまで書いたほうが良いのか？」に関して、ひとまずは次のようなアプローチを取るようにしています。

• ドメインモデルに書く（それはそう）
• SaaS との単純な入出力はインフラ層に書くが、ロジックに相当するものは全てドメインモデルに書く、なるべくインフラ層・アプリケーション層に逃げない
• (option) そもそも設計の段階で、SaaS の色眼鏡を取って、ドメインに落とし込めないか検討する

おわりに

結果的には、SaaS 関係なくドメインのモデリングを頑張りましょうという単純な答えになってしまうのですが、どこまで言っても設計、ひいてはモデリングが重要ですよと原点に戻るのは（大仰ですが）真理だなと思っている今日このごろです 😅