内容が濃すぎてつぶやく暇もなく。ドメイン駆動設計始めようとしてるチームに支援に行くので伝えよう。すでに増田さんの本は推薦しておいたし。 #mixleap
— mono(0w0) (@msts_0w0) 2019年4月4日
以下、当日とったメモ。整理しきれていないけどこのままだといつまでも書けないと思ったのでそのまま。自分用に残す。
Mix Leap Studyについて
- 情報共有を定期的に行う場
- Yahoo社員・社会人・学生の交流
プラットフォームとサービスを支える設計
- クラウドネイティブ
- ヤフーもクラウドネイティブへの移行を進めている
- スクラム(開発プロセス)
- 問題発生のリスク
- 変更が怖い
- スケールできない
- マイクロサービスが密結合
- ドメイン駆動設計
- 設計に洞察力を与えてくれる
思いやりのある命名をしよう
- エヴァンス本:諦める
- 実践ドメイン駆動設計:
- 命名にどれだけ時間使いますか?
- 自分の書いたコードを理解できるようにするため
- 他の人(未来の自分も)がコードを理解できるようにするため
- 良い命名:仕様のどの部分を表現しているかわかりやすい
- 下地
- よく使われる命名を覚える
- ルールを決める
- アンチパターンの場合は、Howを考えて直す
- コードとの距離が遠くなれば情報の鮮度が落ちる
- 伝える方法は目的に応じて選択する
DDDサンプルのお話
- 作った理由:コードが一番具体的、質問も具体的になる
- 核心にある複雑さに立ち向かう
- 設計の大原則:関心の分離・モジュール構造の工夫
- 3つのキーワード
- 要点を絞り込む
- ビジネスルール:データモデルで頑張ろうは書いてない(エヴァンス本)
- 計算モデル:
- 型指向のプログラミング:
- 関心の分離の工夫
- 計算(ビジネスルール)を実行するモジュール群
- データを入出力するモジュール群
- この2つを徹底的に分ける
- モジュール構造の工夫
- サンプルは給与計算アプリケーション
- 給与:Payroll
- ドメイン層
- アプリケーション層
- ビジネスルールの記述を独立させる
- 理論的にはアプリケーション層はシンプルになる
- 現実は複雑な記述が残りやすい
- 要素分解
- Factoryサービス:計算モデルのインスタンスを生成する:データソース層で事実を元に生成
- Queryサービス:計算結果を返す:プレゼンテーション層へ
- Operationサービス:計算結果を記録/通知する:データソース層へ
- 複合サービス(要素サービスをDI)→要素サービス(repositoryをDI)
- 複合はcoordinator:repositoryは見ない
- QA
- データソース層とデータベース
- 計算モデルとデータモデルのマッピング
- 事実としてどのように記録する ことと 事実をどのようにして計算する かはそんなにインピーダンスミスマッチ無いよ
- SELECTの実行=計算用のオブジェクト生成
- 記録すべき事実を持ったオブジェクト=INSERTの実行
- RDBの設計は特定のアプリケーションから独立させる
- イミュータブルデータモデル:事実の履歴+最新状態
- UPDATEは使わない
- 川島さんのスライド
- 制約指向:NOT NULL制約、外部キー制約
- DBに日本語命名が良い
- Mybatisの実装でas句を記載するとresultMapタグがなくなる★
- QA
- coordinatorがまとめて取得してという性能
- データベースの箇所には大量データとの戦いがある
- 業務に本当に必要なのか考える
- プレゼンテーション層