【課外学習 I】Gopher道場〜DDD〜に参加してきました

メルペイが主催しているGopher道場の課外学習としてDDD（ドメイン駆動設計）の勉強会があったので参加してきました。

mercari.connpass.com

Gopher道場については過去記事をご覧ください。

blog.jicoman.info

会場に着くとお酒と美味しい軽食が用意されていたので軽く腹ごしらえ。

gopher-dojo-ddd1

Gopher道場卒業生のために作られたTシャツを受け取ることができました！
妻からも可愛い！と好評でした。

gopher-dojo-ddd2

講師は @pospome 氏です。

twitter.com

DDDの意味を知る

DDD = ドメイン駆動設計 = 業務駆動開発
ドメインってなに？
ドメイン = 問題領域 = ソフトウェアを適用させる業務や関心事
- 業務にソフトウェアを適用する
なぜソフトウェアを適用するのか
- 既存の業務に何かしらの問題があるから
- => 問題領域 = ドメイン = 業務
関心事 = 業務ではないけど何かしらの問題領域
- e.g. Twitter 140文字でつぶやく

DDDのメリット

DDDは既存で抱えていた問題を解決するためのアプローチ
- e.g. nginxはApacheで抱えていた問題(c10kなど)を解決する
DOA = データ中心アプローチ = 既存の業務アプローチ
- 業務で扱うデータ全体をERモデルによってモデル化、正規化して設計する
- DB中心
- DBの特性と目的に合わせたデータ設計になる
  - RDB => リレーショナル
  - NoSQL
- 目的: Read/Writeのワークロード
プログラミング的に最適なデータ構造とは限らない
- 業務上、存在する概念をコード上で扱えない
- モデルのコード構造
例: UserAccount
- ユーザのプロフィール変更するときに何が変更対象なのかがわからない
- 更新対象を分けることで明確化する(UserProfile)が、1対1となるテーブルを用意するのか
例: Boss
- 大ボスのみAttackできるようにする
  - ifによる条件分岐だと可読性が落ちる
- BigBoss, MiddleBossでモデルを分けると明確になる
  - BigBossテーブル, MiddleBossテーブルが必要になってしまう
DOA自体は問題ではなく、DOAによって設計したデータ構造をそのままプログラミングで扱うのが問題
可読性を下げる根本的原因 = 業務とコードの乖離
- 両方理解しないとだが、理解するのは辛い
  - e.g. type, status, flg という謎のカラム
DDDはこれを解決する
プログラミングには、プログラミングに適したデータ構造を利用する
- DBには、DBに適したデータ構造
- 業務を反映したデータ構造 + 振る舞い
  - メソッドや関数も業務に対応している
業務を理解すれば、コードも理解できる状態になる
- 実装詳細に踏み込みやすくなる
DDDの目的 = 可読性をあげること

何をすればDDDになるのか

具体的にどうやるの？
分析
- 業務をコードに落とし込むために分析
設計
- 分析結果をコードに落とし込むための設計
実装
- 成果物 = コード
分析・設計・実装のどれか一つでも欠けるとDDDにならない
- 業務を分析しないで実装だけ(レイヤ構造とかリポジトリパターンとか)をやってもDDDにならない
分析・設計・実装のスケールが大きすぎて、具体的にに説明するのが困難。分かりづらい。DDD本はもっと分厚くならないと

DDDのデメリット

学習コスト
分析コスト
実際可読性があがるかわからない
- 失敗すると可読性があがらない
- パフォーマンスが上がるとかではないのですすめづらい
- 半年〜1年とか開発をすすめていって実感してくる。即時性は低い
モデルとDBのデータ構造が異なる
難易度が高い
DDDで解決できないこと
- 業務が複雑であると、コードも複雑になる
- 実装者の設計スキルが低いと、可読性が落ちる