ドメイン
 「駆動」「開発」 ギルドワークス株式会社
 前川 博志 a.k.a @Posaune
自己紹介 • 前川博志 a.k.a @Posaune • もともと老舗メーカでWindowプログラマ
 ギルドワークス株式会社所属ALMエンジニア • Microsoft MVP for Visual Studio ALM
告知 • 第28回 TFSUG大阪 継続的デリバリーを実現する Team Foundation Server / Visual Studio Online 特集
 https://tfsug.doorkeeper.jp/events/31243
ALM #とは • Application Lifecycle Management • アプリケーションの一生を面倒見るお仕事 • どういう課題から、どういう要求が生まれて、 それをどう実現し、どう確認し、どう運用し、 どう役目を終わらせるか...
アプリーケーションの輪 転生 ※イメージです
ALMエンジニアとしての最近 • ギルドワークスの現場コーチ • 飛び込みCIエンジニアとして主にiOS周りの
 ビルド環境を整備 • CI Serviceにゾッコン中 http://www.slideshare.net/Posaune/jen...
開発者としての最近 • Javaはなんとかかんとかドメイン駆動にしようと
 四苦Hack中 • SwiftはクライアントサイドMVCで画面と実装を
 分離させようと四苦Hack中 • どんなプロジェクトでも、ユーザに一歩踏み込んで
 機能やデザ...
開発・現場での困り事は
 なんでもギルドワークスへ！
こっから本題
@Posauneとドメイン駆動設計
DDDと出会う • 最初の出会いは進められて読んだInfoQのDDD冊子
 （正直つらかった） • 読み進む中で増田さんのBlogを
 発見（そっちは何とか分かる） • とはいえ、実践で使うには至らず
エヴァンス本との出会い
 （一回目） • 頑張って読んだ、けれど・・・ • 正直Value Objectくらいしか頭に残ってな かった（それもThought Worksアンソロジー で頭に入ってたのかも） • やっぱり、「これでやろう」とは思えず
エヴァンス本にすがる
 （二回目） • ある日、結構でかいめのソフトウェアの設計担当に。 • 所謂クライアントサイドMVCを採用したが、Model 層以下の組み方が分からず、画面とデータを直結しか ける • これではいかんとDDD本を読む • ...
アプリケーション層重要 • ドメインをユーザインタフェースから分離す るにはこの一層が必要 • クライアントサイドMVCのMがいきなり
 ドメインオブジェクトと直結されがち • ドメインを隔離することの重要性に
 気づきかける
そしてギルドワークスへ
ギルドワークスとDDD
よくある誤解 • 増田さんのお膝元なんだから、ギルドワーク スはDDD完璧にこなしているんでしょ？
ギルドワークスのDDD事情 • 「誰かが一人頑張ればドメイン駆動設計でき る」なんてことは絶対にない • Ruby / RoR でとにかく動くものを素早く作っ て行くのが主流のスタイルだった • ちょうど今その作り方の壁にぶち当たりつつ あると...
DDDへの期待 • 技術的負債改善へのアプローチ • 素早く・安全な改良を行いたい • エンジニアがお客様の業務にもっと興味を
 もつように
開発クレド http://blog.guildworks.jp/2015/09/02/guildworks_credo/
チームは顧客と利用者の関心事を 反映した、深いモデルとしなやか な設計を追い求めることで、ソフ トウェアを顧客の要望に機敏に対 応できるようにします。
DDDを広めるための取り組み • ドメインの言葉で会話をする • モデリングセッション • “DDD Boot” （考え中） • ちくちく設計鍛錬場
ドメインの言葉で会話する • Slackで技術者の言葉のみで会話してしまう • ほうっておくと、言われたままの設計で作る 技術者に成り下がってしまう • 気をつけないと、gemやライブラリ名や
 代名詞で会話してしまう
こんな感じ • 「devise gem を導入します」 • 「なにそれ。何のために使うの？」 • 「 ユーザーのログイン時にメールでリマインダ 投げる所の実装です。deviseが楽かなぁと」
モデリングセッション • 開発者全員でモデリングをして意識をあわせ ておく • 可能なら、クライアントさんにも入って
 もらい、言葉をあわせていく。 • できるならその場で集まって、ダメなら
 オンラインで共有しながら
DDD Boot • DDDをちゃんとすると、面倒くさい。
 (初期実装でのRoR / gem での立ち上がりにかなわない) • とはいえ、作るのってWeb と REST APIくらいなんだよねぇ • というわけで、テンプレート欲しい • （簡...
ちくちく設計鍛錬場 • ギルドワークス有志でDDD本を読む会 • 特徴：ちくちく読む
「ちくちく読む」とは • 一回（1時間30分くらい）で大体2段落くらい しか進まない • 増田さんセレクトのエッセンスとなる部分を 要約し、表す意味をじっくり考える • 必要に応じて、原著も参照する。
ちくちく読んでいる様子
@Posaune の考えるDDD
突然の(個人的)ブレイクスルー • ドメイン駆動設計の探求 其の一 モデルと実装 を協調させる、とはどういうことか
 http://blog.guildworks.jp/2015/08/12/domain-driven-design-1/ • ...
皆さんにとって設計とは？
皆さんの設計が
 実現されているのは何処？
「コード」ですよね！
本当にそれ「駆動」されてる？ • TDD、BDD
 テストによってコードが駆動される • （狭義の）MDD 
 モデリングによってコードが駆動される • DDD
 ドメインによって、設計書が駆動される？？
ある種の意思決定をすること によって、モデルと実装の協 調が保たれ、互いがもう一方 の効果を高めるようになる。 エリック・エヴァンスのドメイン駆動設計
協調すべきはモデル
 （= ドメイン）と実装。
 
 ドメインに駆動され、
 実装が現れる。
しかし現実は・・・
プロジェクトが障害に突き当 たると、その障害の大小に関 係なく、開発者は、こうした 設計の原則が当てはまらない ように見える状況に自分たち が陥ったと思うかもしれない。 エリック・エヴァンスのドメイン駆動設計
ではどうやって
 ドメインに駆動され
 実装する？
ドメインの設計を、
 ソフトウェアシステムにおけ るその他の大量の関心事から 分離する エリック・エヴァンスのドメイン駆動設計
特定の区別に従ってモデル要 素を定義することで、モデル 要素の意味が鮮明になる。個々 の要素に対して実績のあるパ ターンに従うことで、実際に 実装できるモデルを作れるよ うになる。 エリック・エヴァンスのドメイン駆動設計
• ドメインの関心事を分離し • エヴァンス本に紹介された パターンに適用することで ドメインを実装できる
これは「設計」なんだろうか？
開発者の役割を誤って分割し たために、モデリングが実装 から切り離されてしまい、進 行中の深い分析が設計に反映 されなかった。 エリック・エヴァンスのドメイン駆動設計
DDD is not only Design !! • モデリングして、実装して、フィードバックを 受ける、というライフサイクルそのものが
 ドメイン駆動設計 • 「値オブジェクトとエンティティを分けた」 「レポジトリを使った」「レイヤ分割した...
なんのためにDDDするのか
ソフトウェアの核心は、ドメ インに関係した問題をユーザ のために解決する能力である。 それ以外の特徴はいずれも、 どれほど重要だとしても、こ の基本的な目的を支えるにす ぎない。 エリック・エヴァンスのドメイン駆動設計
「ドメインに駆動される開発」 顧客の問題を解決してくれる
 「使われる」ソフトウェアを作る 顧客の関心事をモデル化し
 それを実装と一致させる レイヤー化アーキテクチャ 値オブジェクト ファクトリ エンティティ サービス Why What How
ソフトウェアの核心にある複 雑さには、真正面から立ち向 かわなければならない。そう しなければ、的外れなソフト ウェアを作ってしまう危険が あるのだ。 エリック・エヴァンスのドメイン駆動設計
核心にある複雑さに立ち向かう • お客さんの関心事で会話をする • お客さんの関心事でモデリングする • お客さんの関心事をソースコードにのせる • お客さんの関心事を常に探り続け、改善しつ づけ、洗練させ続ける
とはいえ、
 まだまだ歩き始めたばかり
今の状況
DDDを武器に、 ソフトウェアの核心を、
 一緒に解きほぐしていきましょう！
仲間を募集中！！
 http://guildworks.jp/contact/
Enjoy, Software Development !!
ドメイン『駆動』『開発』
ドメイン『駆動』『開発』
ドメイン『駆動』『開発』
Upcoming SlideShare
Loading in...5
×

ドメイン『駆動』『開発』

439

Published on

DevLOVE関西 「DDD（ドメイン駆動設計）実践者の話を聞いてみよう」でお話した内容です。
https://devlove-kansai.doorkeeper.jp/events/30012

前半はギルドワークスでのDDD実践の話、後半は@Posauneの解釈するDDDのお話になります。

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
no profile picture user

  • Be the first to comment

No Downloads
Views
Total Views
439
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
1
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

ドメイン『駆動』『開発』

  1. 1. ドメイン
 「駆動」「開発」 ギルドワークス株式会社
 前川 博志 a.k.a @Posaune
  2. 2. 自己紹介 • 前川博志 a.k.a @Posaune • もともと老舗メーカでWindowプログラマ
 ギルドワークス株式会社所属ALMエンジニア • Microsoft MVP for Visual Studio ALM
  3. 3. 告知 • 第28回 TFSUG大阪 継続的デリバリーを実現する Team Foundation Server / Visual Studio Online 特集
 https://tfsug.doorkeeper.jp/events/31243
  4. 4. ALM #とは • Application Lifecycle Management • アプリケーションの一生を面倒見るお仕事 • どういう課題から、どういう要求が生まれて、 それをどう実現し、どう確認し、どう運用し、 どう役目を終わらせるか。 • （個人的解釈です）
  5. 5. アプリーケーションの輪 転生 ※イメージです
  6. 6. ALMエンジニアとしての最近 • ギルドワークスの現場コーチ • 飛び込みCIエンジニアとして主にiOS周りの
 ビルド環境を整備 • CI Serviceにゾッコン中 http://www.slideshare.net/Posaune/jenkinsci-50411288
  7. 7. 開発者としての最近 • Javaはなんとかかんとかドメイン駆動にしようと
 四苦Hack中 • SwiftはクライアントサイドMVCで画面と実装を
 分離させようと四苦Hack中 • どんなプロジェクトでも、ユーザに一歩踏み込んで
 機能やデザイン（意匠）についてディスカッションしてい ます
  8. 8. 開発・現場での困り事は
 なんでもギルドワークスへ！
  9. 9. こっから本題
  10. 10. @Posauneとドメイン駆動設計
  11. 11. DDDと出会う • 最初の出会いは進められて読んだInfoQのDDD冊子
 （正直つらかった） • 読み進む中で増田さんのBlogを
 発見（そっちは何とか分かる） • とはいえ、実践で使うには至らず
  12. 12. エヴァンス本との出会い
 （一回目） • 頑張って読んだ、けれど・・・ • 正直Value Objectくらいしか頭に残ってな かった（それもThought Worksアンソロジー で頭に入ってたのかも） • やっぱり、「これでやろう」とは思えず
  13. 13. エヴァンス本にすがる
 （二回目） • ある日、結構でかいめのソフトウェアの設計担当に。 • 所謂クライアントサイドMVCを採用したが、Model 層以下の組み方が分からず、画面とデータを直結しか ける • これではいかんとDDD本を読む • ようやくレイヤー化アーキテクチャの利点を知る
  14. 14. アプリケーション層重要 • ドメインをユーザインタフェースから分離す るにはこの一層が必要 • クライアントサイドMVCのMがいきなり
 ドメインオブジェクトと直結されがち • ドメインを隔離することの重要性に
 気づきかける
  15. 15. そしてギルドワークスへ
  16. 16. ギルドワークスとDDD
  17. 17. よくある誤解 • 増田さんのお膝元なんだから、ギルドワーク スはDDD完璧にこなしているんでしょ？
  18. 18. ギルドワークスのDDD事情 • 「誰かが一人頑張ればドメイン駆動設計でき る」なんてことは絶対にない • Ruby / RoR でとにかく動くものを素早く作っ て行くのが主流のスタイルだった • ちょうど今その作り方の壁にぶち当たりつつ あるところ
  19. 19. DDDへの期待 • 技術的負債改善へのアプローチ • 素早く・安全な改良を行いたい • エンジニアがお客様の業務にもっと興味を
 もつように
  20. 20. 開発クレド http://blog.guildworks.jp/2015/09/02/guildworks_credo/
  21. 21. チームは顧客と利用者の関心事を 反映した、深いモデルとしなやか な設計を追い求めることで、ソフ トウェアを顧客の要望に機敏に対 応できるようにします。
  22. 22. DDDを広めるための取り組み • ドメインの言葉で会話をする • モデリングセッション • “DDD Boot” （考え中） • ちくちく設計鍛錬場
  23. 23. ドメインの言葉で会話する • Slackで技術者の言葉のみで会話してしまう • ほうっておくと、言われたままの設計で作る 技術者に成り下がってしまう • 気をつけないと、gemやライブラリ名や
 代名詞で会話してしまう
  24. 24. こんな感じ • 「devise gem を導入します」 • 「なにそれ。何のために使うの？」 • 「 ユーザーのログイン時にメールでリマインダ 投げる所の実装です。deviseが楽かなぁと」
  25. 25. モデリングセッション • 開発者全員でモデリングをして意識をあわせ ておく • 可能なら、クライアントさんにも入って
 もらい、言葉をあわせていく。 • できるならその場で集まって、ダメなら
 オンラインで共有しながら
  26. 26. DDD Boot • DDDをちゃんとすると、面倒くさい。
 (初期実装でのRoR / gem での立ち上がりにかなわない) • とはいえ、作るのってWeb と REST APIくらいなんだよねぇ • というわけで、テンプレート欲しい • （簡単なのは）もうあるよ 
 https://github.com/system-sekkei/isolating-the-domain
  27. 27. ちくちく設計鍛錬場 • ギルドワークス有志でDDD本を読む会 • 特徴：ちくちく読む
  28. 28. 「ちくちく読む」とは • 一回（1時間30分くらい）で大体2段落くらい しか進まない • 増田さんセレクトのエッセンスとなる部分を 要約し、表す意味をじっくり考える • 必要に応じて、原著も参照する。
  29. 29. ちくちく読んでいる様子
  30. 30. @Posaune の考えるDDD
  31. 31. 突然の(個人的)ブレイクスルー • ドメイン駆動設計の探求 其の一 モデルと実装 を協調させる、とはどういうことか
 http://blog.guildworks.jp/2015/08/12/domain-driven-design-1/ • ドメインに「駆動」されて「設計」するとは
 どういうことか、という気付き

  32. 32. 皆さんにとって設計とは？
  33. 33. 皆さんの設計が
 実現されているのは何処？
  34. 34. 「コード」ですよね！
  35. 35. 本当にそれ「駆動」されてる？ • TDD、BDD
 テストによってコードが駆動される • （狭義の）MDD 
 モデリングによってコードが駆動される • DDD
 ドメインによって、設計書が駆動される？？
  36. 36. ある種の意思決定をすること によって、モデルと実装の協 調が保たれ、互いがもう一方 の効果を高めるようになる。 エリック・エヴァンスのドメイン駆動設計
  37. 37. 協調すべきはモデル
 （= ドメイン）と実装。
 
 ドメインに駆動され、
 実装が現れる。
  38. 38. しかし現実は・・・
  39. 39. プロジェクトが障害に突き当 たると、その障害の大小に関 係なく、開発者は、こうした 設計の原則が当てはまらない ように見える状況に自分たち が陥ったと思うかもしれない。 エリック・エヴァンスのドメイン駆動設計
  40. 40. ではどうやって
 ドメインに駆動され
 実装する？
  41. 41. ドメインの設計を、
 ソフトウェアシステムにおけ るその他の大量の関心事から 分離する エリック・エヴァンスのドメイン駆動設計
  42. 42. 特定の区別に従ってモデル要 素を定義することで、モデル 要素の意味が鮮明になる。個々 の要素に対して実績のあるパ ターンに従うことで、実際に 実装できるモデルを作れるよ うになる。 エリック・エヴァンスのドメイン駆動設計
  43. 43. • ドメインの関心事を分離し • エヴァンス本に紹介された パターンに適用することで ドメインを実装できる
  44. 44. これは「設計」なんだろうか？
  45. 45. 開発者の役割を誤って分割し たために、モデリングが実装 から切り離されてしまい、進 行中の深い分析が設計に反映 されなかった。 エリック・エヴァンスのドメイン駆動設計
  46. 46. DDD is not only Design !! • モデリングして、実装して、フィードバックを 受ける、というライフサイクルそのものが
 ドメイン駆動設計 • 「値オブジェクトとエンティティを分けた」 「レポジトリを使った」「レイヤ分割した」
 だけではドメイン駆動設計ではない！
  47. 47. なんのためにDDDするのか
  48. 48. ソフトウェアの核心は、ドメ インに関係した問題をユーザ のために解決する能力である。 それ以外の特徴はいずれも、 どれほど重要だとしても、こ の基本的な目的を支えるにす ぎない。 エリック・エヴァンスのドメイン駆動設計
  49. 49. 「ドメインに駆動される開発」 顧客の問題を解決してくれる
 「使われる」ソフトウェアを作る 顧客の関心事をモデル化し
 それを実装と一致させる レイヤー化アーキテクチャ 値オブジェクト ファクトリ エンティティ サービス Why What How
  50. 50. ソフトウェアの核心にある複 雑さには、真正面から立ち向 かわなければならない。そう しなければ、的外れなソフト ウェアを作ってしまう危険が あるのだ。 エリック・エヴァンスのドメイン駆動設計
  51. 51. 核心にある複雑さに立ち向かう • お客さんの関心事で会話をする • お客さんの関心事でモデリングする • お客さんの関心事をソースコードにのせる • お客さんの関心事を常に探り続け、改善しつ づけ、洗練させ続ける
  52. 52. とはいえ、
 まだまだ歩き始めたばかり
  53. 53. 今の状況
  54. 54. DDDを武器に、 ソフトウェアの核心を、
 一緒に解きほぐしていきましょう！
  55. 55. 仲間を募集中！！
 http://guildworks.jp/contact/
  56. 56. Enjoy, Software Development !!

  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×