[登壇レポート]マイクロサービスアーキテクチャにおけるDDD | Lightning TechTalks〜New Server Side Engineers〜
はじめに
Finatextエンジニアの小林です。
先日2023年8月1日に開催された、Lightning TechTalks〜New Server Side Engineers〜にて、LTをしてきました！
会の趣旨としては
今の会社に入社してそんなに時間が経っていないサーバサイドエンジニアの皆さんに、新しい職場でやったことを話す登壇練習の場として使ってもらいたい
ということで、自分がFinatextに勤めてから半年弱で取り組んできた内容について、アウトプットに取り組んでまいりました。
本記事では登壇内容について少し補足しながら紹介し、今後の展望を膨らませていきます。
登壇内容の紹介
👇発表資料
今回私は、現在進行形で開発している投資信託の直販サービスについて、そのアーキテクチャ設計の中で考えたことを題材にしました。
Finatextの提供する証券サービスは、証券取引の基礎的な機能を提供するプラットフォーム”BaaS”を利用して開発することで、開発コストを抑えスピーディーに価値提供を行うことができる、という特徴を持っています。
このBaaSはマイクロサービスアーキテクチャで構成されているのですが、各マイクロサービスがAPIで返す値は、一般的にイメージされるドメインオブジェクトの単位ではなく、ある業務を行う際に必要な単位になっています。具体的にいうと、投資信託のスポット買付をするときには、購入するファンドの情報や顧客の口座種別、顧客の余力など、さまざまなドメインの情報をやりとりする必要があります。
ここでチームメンバーから提示された案が、CQRS(Command and Query Responsibility Segregation)です。ドメインモデルの集約と合わない単位でデータを扱う必要が出てきたとき、そのユースケースに応じたオブジェクトを新たに設けるというやり方です。今回の開発では注文時に扱う情報が複数ドメインにまたがっていることを受け、外接のインターフェースをドメイン層ではなくユースケース層に持つことにしました。
また、BaaSへの接続方法についても工夫を加えました。先ほど注文業務の際にはファンドの情報も扱うという話をしましたが、実はBaaSの中にはファンドの情報を専門に扱うモジュールもあること、またサービス内でファンド情報を扱うユースケースは他にもあることから、BaaSの使い方としては少し非効率にはなってしまいますが、注文用のモジュールとは別にファンド用のモジュールにも接続する形式を採用しました。
このように、マイクロサービスをプラットフォームとして運用していくには、さまざまな形でのドメインモデリングを考える必要があります。私は今回の一件から、ドメイン駆動開発で大切なのは形式的なモデリングではなく、実際の業務に即したモデリングを行うこと、そして変更容易性を保った設計にすることだということを学びました。実際に開発を行いながらチーム内で議論し、より良い設計を目指してブラッシュアップしていくことの大切さを実感した、非常に濃い経験でした。
採用情報
Finatextではエンジニアを募集しています！マイクロサービスアーキテクチャや証券ドメインのモデリングに興味のある方は、以下のリンクからFinatextについてチェックしてみてください！我々と一緒に、より良い金融の基盤を作っていきましょう！
