DDDお悩み相談事例シーズン1

1.

DDDお悩み相談事例シーズン1 かとじゅん(@j5ik2o)

2.

作る対象やその規模にかかわらず、DDDは有用か？ • 有用。一般的には何らかの問題を解決するのがシステムの目的。ゆえにドメインが存在しないシステムはありえないと考えて差し支えない。 • ただし、業務システムに対するプレゼンテーションの役割を果たすシステムでは、CRUDが主目的になるこ
とがある帳票システム業務システム業務の結果をCRUDする Command Query ドメインリードモデルイベント

3.

フロントエンドはDDDと関係ないのでは？ • ビジネスロジックがサーバサイドだけにあるなら、フロントエンドは完全なユーザインターフェイス層。しかし、クライアントサイドにもドメインロジックはありえる • たとえば、オークションサイトなら出品物の落札期限が文字列表現としてREST APIな
どのレスポンスで返ってくるので、クライアントはそのまま表示します。しかし落札までの残り時間はクライアントで計算しなければなりません出品ドメインオブジェクト出品DTO 落札期限出品ビュー出品ドメインオブジェクト落札残り時間クライアントサーバ

4.

DDDに共通の課題感があってそれを乗り越えた方法の一つがCQRSだったのか？ • GregさんがCQRS and Event Sourcingのアイデアを公表したのが2010年ぐらい。コミュニティでも盛り上がったのは2011年。 •
Chatworkでは2016年末にKafka, HBase, Akkaを使ってEvent Sourcingシステムをリリースしている。 • Akkaでは分散システム上でEvent Sourcingを実装する手段を提供している ◦ akka-persistence ◦ akka-cluster-sharding • event store(https://eventstore.org/) が選択肢のひとつ

5.

レガシーシステムへのDDD導入方法は？ • 「コアドメインの中で仕事をする」・「ユビキタス言語を作って使う」・「モデルを実装に反映する」の三本柱。どれが掛けてもよくない。局所的でも三本柱を立てる。例えば、リファクタリングなら、ユニットに閉じて三本柱を立てる • レガシーシステムの改善にはDDD以外の考え方が必要。「レガシーシステム改善ガイド」読みましょう。改善の道はリファクタリング→リアーキティング→リライトの階段を登る。いきなりリライトではない •
実装のミクロな視点でいえば、データとロジックを統合して値オブジェクト化を進める。数量はただのIntではない。電話番号はただのStringではない。ビジネスルールに基づく計算能力を持つオブジェクトという前提に立つ

6.

売上リポジトリ DAOとリポジトリの違いは？ • DAOはDBのテーブルの行をI/O する責務。リポジトリは生成済みの集約の参照を取得したり削除するための責務。 • 集約とテーブルが一対一対応していても責務としては異なる。集約
はどんな永続化技術からも中立 • ビジネスロジックに入出力に関係する知識を含めない。責務重複の回避売上集約売上エンティティ売上詳細ローカルエンティティ売上DAO 売上レコード売上詳細レコード売上詳細DAO 永続化責務から解放されなければならない

7.

おしまい

DDDお悩み相談事例シーズン1

DDDお悩み相談事例シーズン1

かとじゅん

Want more?

Transcript