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

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

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

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/) が選択 肢のひとつ

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

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

おしまい