Submit Search
Upload
某S社のddd(メイリオ)
•
Download as PPTX, PDF
•
20 likes
•
7,743 views
kumake
Follow
2015/08/07 DDD 勉強会
Read less
Read more
Software
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 35
Download now
Recommended
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
Hiroshima JUG
RDRA DDD Agile
RDRA DDD Agile
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計入門
ドメイン駆動設計入門
Takuya Kitamura
ドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計する
増田 亨
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
Recommended
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
概念モデリング再入門 + DDD
概念モデリング再入門 + DDD
Hiroshima JUG
RDRA DDD Agile
RDRA DDD Agile
増田 亨
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
ドメイン駆動設計入門
ドメイン駆動設計入門
Takuya Kitamura
ドメイン駆動設計 分析しながら設計する
ドメイン駆動設計 分析しながら設計する
増田 亨
ドメイン駆動で開発する ラフスケッチから実装まで
ドメイン駆動で開発する ラフスケッチから実装まで
増田 亨
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
増田 亨
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Yusuke Suzuki
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
Tetsutaro Watanabe
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
私にとってのテスト
私にとってのテスト
Takuto Wada
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2
増田 亨
インセプションデッキの紹介
インセプションデッキの紹介
lita
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
Mao Ohnishi
楽天エンジニアライフ
楽天エンジニアライフ
Rakuten Group, Inc.
More Related Content
What's hot
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
増田 亨
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
増田 亨
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
Yusuke Suzuki
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
SpringBootTest入門
SpringBootTest入門
Yahoo!デベロッパーネットワーク
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
Yusuke Suzuki
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
増田 亨
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
Akihiro Kuwano
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
Tetsutaro Watanabe
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
私にとってのテスト
私にとってのテスト
Takuto Wada
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
増田 亨
ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2
増田 亨
インセプションデッキの紹介
インセプションデッキの紹介
lita
What's hot
(20)
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
「ドメイン駆動設計」の複雑さに立ち向かう
「ドメイン駆動設計」の複雑さに立ち向かう
実践に向けたドメイン駆動設計のエッセンス
実践に向けたドメイン駆動設計のエッセンス
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
なぜ「マイクロサービス“化”」が必要なのか
なぜ「マイクロサービス“化”」が必要なのか
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
SpringBootTest入門
SpringBootTest入門
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
サービスブループリントによるシステム設計手法の紹介 - XP祭り2022
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
AWSのログ管理ベストプラクティス
AWSのログ管理ベストプラクティス
データサイエンティスト向け性能問題対応の基礎
データサイエンティスト向け性能問題対応の基礎
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
私にとってのテスト
私にとってのテスト
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
実践的な設計って、なんだろう?
実践的な設計って、なんだろう?
ドメイン駆動設計(DDD)の実践Part2
ドメイン駆動設計(DDD)の実践Part2
インセプションデッキの紹介
インセプションデッキの紹介
Similar to 某S社のddd(メイリオ)
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
Mao Ohnishi
楽天エンジニアライフ
楽天エンジニアライフ
Rakuten Group, Inc.
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
Toshiyuki Hirata
新規事業を加速させる技術
新規事業を加速させる技術
Mao Ohnishi
InDesign正規表現勉強会_名古屋_0727
InDesign正規表現勉強会_名古屋_0727
ShinyaNakagawa
Spark MLlibではじめるスケーラブルな機械学習
Spark MLlibではじめるスケーラブルな機械学習
NTT DATA OSS Professional Services
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Preferred Networks
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Takashi Someda
Xcodeの管理を楽に - Jenkins編 -
Xcodeの管理を楽に - Jenkins編 -
Toshiyuki Hirata
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
Masataka Sato
コードレビューをより良くする Danger x Android
コードレビューをより良くする Danger x Android
Toshiyuki Hirata
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
DeNA
DeNAにおけるSWETの役割
DeNAにおけるSWETの役割
Toshiyuki Hirata
クラウド活用で実現する、開発・保守の効率化
クラウド活用で実現する、開発・保守の効率化
Hiroshi Koyama
サーバーレスの話
サーバーレスの話
真吾 吉田
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
株式会社スカイアーチネットワークス
ここが良かったDatadog
ここが良かったDatadog
tyamane
[CTO Night & Day 2019] ML services: MLOps #ctonight
[CTO Night & Day 2019] ML services: MLOps #ctonight
Amazon Web Services Japan
スマートフォンWebアプリ最適化”3つの極意”
スマートフォンWebアプリ最適化”3つの極意”
Koji Ishimoto
Xamarin概要と活用方法
Xamarin概要と活用方法
Yoshito Tabuchi
Similar to 某S社のddd(メイリオ)
(20)
20151110 ドメイン駆動設計によるサービス開発
20151110 ドメイン駆動設計によるサービス開発
楽天エンジニアライフ
楽天エンジニアライフ
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
iOSアプリ開発のテスト環境 - テストをはじめる最初の一歩 -
新規事業を加速させる技術
新規事業を加速させる技術
InDesign正規表現勉強会_名古屋_0727
InDesign正規表現勉強会_名古屋_0727
Spark MLlibではじめるスケーラブルな機械学習
Spark MLlibではじめるスケーラブルな機械学習
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Cloud operator days tokyo 2020講演資料_少人数チームでの機械学習製品の効率的な開発と運用
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Backlog、Cacoo にみるAWS運用の勘所 - JAWS UG 三都物語
Xcodeの管理を楽に - Jenkins編 -
Xcodeの管理を楽に - Jenkins編 -
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
1ヶ月で作り切る!スタートアップのための Rails 爆速開発術 (20170306)
コードレビューをより良くする Danger x Android
コードレビューをより良くする Danger x Android
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
Mobage/AndAppのSDK開発事例とSDKを作る際に知っておくべきこと #denatechcon
DeNAにおけるSWETの役割
DeNAにおけるSWETの役割
クラウド活用で実現する、開発・保守の効率化
クラウド活用で実現する、開発・保守の効率化
サーバーレスの話
サーバーレスの話
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
スカイアーチセミナー:自社アプリをクラウド展開する為の『失敗しない3つの法則
ここが良かったDatadog
ここが良かったDatadog
[CTO Night & Day 2019] ML services: MLOps #ctonight
[CTO Night & Day 2019] ML services: MLOps #ctonight
スマートフォンWebアプリ最適化”3つの極意”
スマートフォンWebアプリ最適化”3つの極意”
Xamarin概要と活用方法
Xamarin概要と活用方法
某S社のddd(メイリオ)
1.
某 S 社
の DDD -どうしてこうなった駆動開発- @kumake1004
2.
自己紹介 名前@kumake1004 ‒ Sansan 株式会社
アプリケーションエンジニア ‒ 2011年入社 (5年目) 仕事 ‒ 法人向け名刺管理アプリのサーバーサイド実装 ‒ アプリエンジニアとインフラエンジニアの板挟みにあうこと 興味 ‒ .NET (C#) / DDD / テスト / マネジメント
3.
どうしてこうなった駆動開発とは 職場で DDD 導入したら失敗しました ‒
(個人の感想です) 再挑戦を始めたところ、、、 ‒ 漠然と思いはあって、良い機会なので振り返って言語化します ‒ という普通の失敗事例紹介 つまりただの出オチ
4.
- 実践ドメイン駆動設計 コアドメイン
(スクラム) における集約の使用 “彼らには DDD の経験があまりなかった。そのため、チームは DDD に関 してちょっとした間違いを犯した。” “最終的に彼らは、自分たちが集約を扱った経験を糧にして成長した。私達も 同じように成長できるはずだ。彼らの悪戦苦闘ぶりから学び、自分たちのソ フトウェアを作るときに同じ状況に陥らないようにしよう。”
5.
DDD 導入の背景 名刺管理 Web
アプリケーション ‒ C# / ASP.NET / PostgreSQL 他 ‒ 生まれて 8 年なので色々つらい(トランザクションスクリプトはやだ!) ‒ もっと早くて質の良いソフトウェアを開発できないか? どうやって? ‒ 3 年くらい前に大きな新機能追加がきた ‒ この機会に設計や実装を見直そう ‒ DDD っていうのがあるらしい。流行ってる
6.
DDD どうだった? 導入に失敗した ‒ (個人の感想です) どうなった? ‒
仕様を読み解くのが大変 ‒ 以前に比べて生産性が下がった ‒ 品質も特に上がってない
7.
DDD どうだった? いいこともある ‒ 実装の共通化への意識は上がった気がする ‒
レイヤの役割は以前より明確になった ‒ まれに生産性が大きく上がることがある
8.
失敗の原因 まぁ勉強不足 ‒ 正しいけど話終わっちゃうので ‒ 以降の話はいったんこれを忘れてお聞きください
9.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
10.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
11.
ひとつのモジュールに詰め込みすぎた 事象 ‒ 全部同じ名前空間 ‒ 文脈が分からないので使っていいか分からず、もしくは普通に見つからず再 利用が進まない ‒
勇気を出して使うとある日突然全く関係ない(と思った)修正でバグる 原因 ‒ ドメインモデル(図)を書かないから境界が分からない ‒ 再利用の可能性を捨てきれない(お前が思っているほど汎用的ではない)
12.
ひとつのモジュールに詰め込みすぎた 反省 ‒ とにかくドメインモデル(図)を書く ‒ 再利用は(いったん)忘れる ‒
分けすぎは(多分)「継続的な統合」でなんとかなる ‒ 分けなさすぎを分けるのは大変 • 影響範囲とか
13.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
14.
ユビキタス言語やモデル(図)がない 事象 ‒ 文脈が読み取れないので影響範囲が分からない ‒ ドメインエキスパートが加わらない
= 実装者の視点になってしまう ‒ 実装視点になる =「意図の明白なインタフェース」にならない 原因 ‒ 面倒(実際面倒) ‒ ドメインエキスパートが嫌がる ‒ チームメンバーも嫌がる
15.
ユビキタス言語やモデル(図)がない 反省 ‒ 自分だけのものでよいので作る ‒ WHY
を説明してもイマイチ ‒ それより、しつこく図を使って、価値があることを分かってもらう • 何か話す時には図を見せながら説明する • 何か質問されたらとりあえず図を出して考えるふりをする(実績あり)
16.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
17.
リポジトリだけ頑張りすぎた 事象 ‒ 高度な抽象化と汎用性を兼ね備えた高機能リポジトリ ‒ Entity
Framework を想像してもらったら大体合ってます ‒ 自分たちで作ってしまったので、リポジトリ追加するときが苦行
18.
19.
リポジトリすごい 上手く流用できると ‒ かなり便利で生産性も上がる 裏はどんな実装なのか? ‒ 式を全て
Expression で保持 ‒ SQL 発行直前に、Expression から自分で SQL 構築 ← え?
20.
SELECT 文の作成処理 ‒ つらい リポジトリがあまり作られない ‒
楽をするためにリポジトリラッパーが氾濫 • HogeGetService クラス ‒ どうしようもないときは既存クラスを拡張 • さらに巨大に ‒ つらい
21.
リポジトリだけ頑張りすぎた 原因 ‒ ひとつの集約や Entity
に関わるテーブルが多すぎる ‒ インフラ層の課題をインフラ層で解決しなかった • Entity Framework 使えない • SQL が複雑で、複雑な抽出条件をもらわないとデータアクセス出来ない、速度出ない 反省 ‒ 集約や Entity は小さく • Unit Of Work、結果整合性 ‒ インフラ層の課題をドメインモデルに寄せない • SQL リファクタリング、SQL チューニング、キャッシュ
22.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
23.
遅い 事象 ‒ 遅ォォォォォいッ説明不要!! ‒ 具体的には
Entity の復元が遅い 原因 ‒ ひとつの集約や Entity に関わるテーブルが多すぎるので SELECT 遅い ‒ キャッシュしてないので SQL の発行回数が多い ‒ リフレクション
24.
遅い 反省 ‒ DDD はインフラ層の問題を解決しない ‒
CQRS、キャッシュを検討する ‒ リフレクションによる自動化ではなく、テンプレートによる自動化 ‒ 集約や Entity を小さく保つ
25.
やらかし一覧 ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
26.
大きく始めた 事象 ‒ 全実装の 1/5
がいきなり DDD に ‒ 失敗の予感を感じても方向転換したり引き返せない ‒ 今更違う設計にもできず、負債を産む機械になってしまった 原因 ‒ レガシーを憎みすぎた ‒ 自分たちの力量を客観視できていなかった
27.
大きく始めた 反省 ‒ 始めは小さく、段々大きく ‒ レガシー、意外といいやつじゃん •
「Sansan はレガシーでよかったんですよ!」発言(実話) ‒ DDD にすべき箇所とそうでない箇所がある
28.
やらかし一覧 なんでもサービスにしてしまった ひとつのモジュールに詰め込みすぎた ユビキタス言語やドメインモデル(図)を作らなかった リポジトリだけ頑張りすぎた 遅い 大きく始めた その他
29.
その他 万能 Service ‒ 実装場所に困ったら
Service ‒ 困って無くてもとりあえず Service
30.
その他 ドメインモデル貧血症 or Fat
Model ‒ サービスが万能過ぎて実際やることない ‒ 意識高い系 Entity (超でかい)
31.
その他 お?Value Object ってフォルダがあるな。。。 ‒
開いて見てみる ‒ Value Object じゃなかった _人人人人人人人人人人人人人人_ > Value Object じゃなかった <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ^Y ̄
32.
まとめ
33.
どうしてこうなった Iterative に作らなかった ‒ DDD
ってこういうことねで実装 => 振り返りがないので間違いに気づけな い レガシーの課題を継承してしまった ‒ 新しい仕組みに気をとられて、レガシーの問題を整理できなかった ドメインモデル(図)を作らなかった ‒ ドメインエキスパート視点での関心事を明確に出来ない ‒ メンタルモデルと実装が結びつかないので冗長になっただけ
34.
どうしてこうなった、からの 基本に忠実に、振り返りながら ‒ 特にドメインモデル(図)を必ず作る • 面倒だけど絶対に役に立つ。上手く出来なくても過程だけでも大事 ‒
小さく始める 適用範囲を絞る ‒ レガシーも一概に悪ではない 失敗から学ぼう ‒ どうしてこうなった?と思ったときはある意味チャンスでもある ‒ ささいな失敗経験の積み重ねが応用に活きてくるので、みんなも失敗事例を共有してください
Download now