O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

2015-12-16 某S社、出直しDDDってるってよ

3.572 visualizações

Publicada em

2015/12/16 Sansan DDD 勉強会#2

Publicada em: Software
  • Seja o primeiro a comentar

2015-12-16 某S社、出直しDDDってるってよ

  1. 1. 某S社、 出直しDDDってるってよ @atsukanrock & @kumake1004
  2. 2. 自己紹介 @atsukanrock @kumake1004
  3. 3. 前回までのあらすじ DDD (どうしてこうなった駆動開発)がスベった
  4. 4. DDD に挑戦したが、失敗 • どうして? • ドメイン駆動しなかった(ユビキタス言語?何それ?) • チームの意思を統一できなかった • 旧アーキテクチャを切り離せなかった • 大きく始めた • 次はどうする? • 実装以外の部分も大切にする • 旧アーキテクチャと切り離す • 小さく始める
  5. 5. 出直しの背景 いろいろつらかった
  6. 6. 自作 Repository (v2 Repository *1) がつらい • 作るのが大変 & レビューしづらい & 変更するのが大変 • 各具象 Repository の実装で Expression をこねる • Expression -> SQL 変換が自前 • 各具象 Repository のコード量が多い • ステートフル • Unit of Work がない *1: v2 アーキテクチャにおける Repository のこと。その前には v1 アーキテクチャもあった
  7. 7. v2 Repository の例 • インターフェイス部分 https://github.com/eightcard/lk-linkknowledge/blob/master/common/Repository/StackRepository.cs • Expression -> SQL 変換部分 https://github.com/eightcard/lk-linkknowledge/blob/master/common/Repository/Npgsql/StackQueryBuilder.cs
  8. 8. 旧データアクセス基盤がつらい • 自作の sharding 対応データアクセス基盤だが… • データアクセス基盤なのになぜか HttpContext に依存 • マルチスレッドで壊れる (ことがある) • ステートフルオブジェクトをキャッシュ • デバッグ実行しても何が起こっているか分からない
  9. 9. 旧データアクセス基盤 • HttpContext に依存 https://github.com/eightcard/lk-linkknowledge/blob/master/common/Base/Base.cs • ステーフル https://github.com/eightcard/lk-linkknowledge/blob/master/common/Base/DbmsHelper.cs
  10. 10. このままではまずい • 新しいアーキテクチャを考案すべき • リスク比較: 新旧アーキテクチャの混在 ≪ v2 Repository が量産され続ける • アーキテクチャ移行戦略: がんばる (しかない)
  11. 11. 出直し後の DDD その一部をお見せします
  12. 12. 選択式アーキテクチャスタイル • 実装する機能の性質に応じて以下から選択 • Transaction Script • Dapper を使う • Domain Model (DDD) • Unit of Work あり: Entity Framework を使う • Unit of Work なし: Dapper を使う • DDD アーキテクチャにも向き不向きがある • 例: 大量更新が前提のバッチアプリケーションには不向き • スタイル選択チャート https://sansan.atlassian.net/wiki/pages/viewpage.action?pageId=26050721
  13. 13. Transaction Script using Dapper
  14. 14. Domain Model using Entity Framework
  15. 15. Domain Model using Dapper
  16. 16. Layer をきちんと分割する • Layer 毎にアセンブリを分ける • Layer の依存関係をアセンブリの依存関係で強制 • アセンブリの循環参照はできない (ビルドエラー) • テクノロジー依存部分は Infrastructure Layer に閉じ込める • インターフェイスは Domain / Application Layer に • DI によって実装クラスのインスタンスを注入 • ユニットテスト時に Mock を挿せるように
  17. 17. Component の責務を正しく理解する • Component とは Entity とか Repository とかのこと • 誤認識の実例: • Application Service と Domain Service が区別されていない • DTO が Value Object と呼ばれている
  18. 18. Bounded Context を切る • 関心の分離 • 名前空間や Entity の肥大化を防ぐ • カラム数が多いテーブルでも、Bounded Context を切れば 対応する Entity の肥大化を防げる • 1 つの Bounded Context から見れば必要なプロパティは少ない • Namespace Guideline https://github.com/eightcard/lk-linkknowledge/blob/33t/coding- standard/feature/csharp/Document/CodingStandard/CSharp.md#名前空間の名前
  19. 19. v3 Repository (Code Name: Relaxed Repository) • Entity Framework (EF) Code First を採用 • Expression をこねない • SQL 構築は EF にやらせる • そもそも DbContext は Unit of Work + Repository https://msdn.microsoft.com/library/system.data.entity.dbcontext.aspx • インターフェイスを切って薄くラップすれば良い • 新データアクセス基盤 (Sansan.Data) を利用 • ステートレス • 議論の跡 https://sansan.atlassian.net/wiki/display/~kanbara/Relaxed+Repository
  20. 20. Domain Event (詳しくは次回以降に) • 主たる Domain ロジックから副次的な処理を切り離す • 例: メール通知、行動分析 / 監査用ログ収集 • メッセージングテクノロジー (例: Amazon SQS) を利用する • Fault Tolerant になる • 共通的なリトライの仕組み • 何度やっても成功しなかった処理は Dead Letter Queue に残る • 並列分散処理により高速化が可能 • 設計は複雑化する • Distributed / Compensating Transaction
  21. 21. 出直し後の DDD チームビルディング
  22. 22. 体制と方針 • DDD をやるという意思統一 • ドメインモデル図、ユビキタス 言語を見える形で作る
  23. 23. ユビキタス言語 • ドキュメントを作成 • https://sansan.atlassian.net/wiki/pages/viewpage.action?pageId=2123375 2 • PM との会話やユースケースで出てくる単語を拾う • 実装からのフィードバックはチームで相談 • 利用意識を徹底
  24. 24. ユビキタス言語へのこだわり
  25. 25. ドメインモデル
  26. 26. 全員でモデリング
  27. 27. どうなった? • ドメインについての共通認識を持てた • 以前より気軽にチームメンバに相談できるように • 相談を繰り返して共通認識がさらに強化される正のスパイラル • 開発から PM へドメイン知識のフィードバック • 間違った方向へ進もうとしていることに早めに気付けるように • ユビキタス言語、ドメインモデルが考え方の基準になる • 今考えていることと比較、検証 • 実装が業務を反映 • 会話の内容と実装が同じなので読んで理解もしやすい
  28. 28. 新人にとってどうか? (新人 Y の証言) • 最初はきつい • 入りたては何言ってるか意味不明(ハイコンテキストになる) • 慣れたらむしろ楽 • ドキュメントが役に立った • 意味が統一されているので、一カ所理解すれば全体の理解に繋がる • 新人による再モデリングという解決 • http://www.slideshare.net/maoohnishi3/20151110-54980095/71 • ドメインエキスパートと「会話 (議論)」できるように • ドメインの理解が不足していて、自分の意見に自信が持てていなかった • ユビキタス言語&モデルで PM と対等に議論ができるように
  29. 29. 課題は? • ドメインエキスパートにもっとフィードバックを • 「画面デザイン仕様書だけあればいいじゃん」 • ドメインモデルでの会話が難しい • 初期コスト • ネーミング、ユビキタス言語やドメインモデルの構築 • 旧体制のままの開発プロセス • 変更に強くしたが、変更されない (機会が少ない) • プロジェクトごとに作られるチーム • どうやって知識を継承していくか?
  30. 30. ご清聴 ありがとうございました

×