Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話
Search
Satoshi Kawashima
October 12, 2019
Technology
7
5.1k
社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話
BASE, Inc. で社内勉強会を開くときに考えた、僕らの学習アプローチと勉強会設計について話しました。
Satoshi Kawashima
October 12, 2019
Tweet
Share
More Decks by Satoshi Kawashima
See All by Satoshi Kawashima
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
nazonohito51
17
8.6k
BASE大規模リアーキテクチャリング / base_rearchitecturing
nazonohito51
17
11k
既存サービスに後からR/W Splittingライブラリを入れる時に考えたこと / r-w-splitting
nazonohito51
1
28k
CakePHP2でもPhpStormがコード補完してくれるようにした話 / cakephp2-ide-helper
nazonohito51
1
2.2k
PHPStanでCustomRuleを作る / Make PHPStan CustomRule
nazonohito51
5
3.8k
単方向依存を実現する静的解析ライブラリのご紹介 / Analyze PHP Dependencies
nazonohito51
2
5.5k
「SOLIDの原則って何ですか?」って質問に答えたかった / What's SOLID principle
nazonohito51
4
1.8k
ドキュメントルート配下に全てのPHPファイルが置かれていた環境をindex.phpだけにした話 / document root
nazonohito51
1
3.7k
アジャイル開発でのソフトウェア設計
nazonohito51
0
810
Other Decks in Technology
See All in Technology
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
32k
生成AIのガバナンスの全体像と現実解
fnifni
1
190
Amazon SageMaker Unified Studio(Preview)、Lakehouse と Amazon S3 Tables
ishikawa_satoru
0
160
AWS re:Invent 2024で発表された コードを書く開発者向け機能について
maruto
0
190
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
36
14k
生成AIをより賢く エンジニアのための RAG入門 - Oracle AI Jam Session #20
kutsushitaneko
4
240
10分で学ぶKubernetesコンテナセキュリティ/10min-k8s-container-sec
mochizuki875
3
350
事業貢献を考えるための技術改善の目標設計と改善実績 / Targeted design of technical improvements to consider business contribution and improvement performance
oomatomo
0
100
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1.1k
Wantedly での Datadog 活用事例
bgpat
1
490
コンテナセキュリティのためのLandlock入門
nullpo_head
2
320
DevFest 2024 Incheon / Songdo - Compose UI 조합 심화
wisemuji
0
110
Featured
See All Featured
Scaling GitHub
holman
458
140k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
BBQ
matthewcrist
85
9.4k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
98
A Philosophy of Restraint
colly
203
16k
Docker and Python
trallard
42
3.1k
We Have a Design System, Now What?
morganepeng
51
7.3k
Adopting Sorbet at Scale
ufuk
73
9.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Practical Orchestrator
shlominoach
186
10k
Transcript
© - BASE, Inc. 社内勉強会で OOPと CleanArchitectureと DDDを 勉強し始めたというお話 川島
慧 / BASE, Inc. / / PHPカンファレンス沖縄
© - BASE, Inc. Product Division 川島 慧 @nazonohito
© - BASE, Inc. これは何? • 社内で勉強会とか始めた話 • 何持ち帰れるの? •
弊社のOOP/CleanArchitecture/DDDに対する学習アプローチ と勉強会を設計について考えたことを共有 • OOP/CleanArchitecture/DDDそのものについては話しません • 開催して間もないため結果などはほとんど話せません
経緯
© - BASE, Inc. 「OOPの勉強会したい」
© - BASE, Inc. じゃあやるか
© - BASE, Inc. 翌⽇にカレンダー登録
© - BASE, Inc. ノープランで当⽇
photos by Rick Cogley https://www.flickr.com/photos/rickcogley/ 飲み会の勢いで開始
⽬標設定
© - BASE, Inc. 理論と実践をつなげる ⽬標
© - BASE, Inc. 経緯 • 今年のはじめにオブジェクト 指向設計読書会をやっていた
© - BASE, Inc. 業務で使うイメージがわかない (⼀部の)参加者の感想
© - BASE, Inc. オブジェクト指向設計実践ガイド • 単⼀責任のクラスを設計する • 依存関係を管理する •
柔軟なインターフェースを作る • ダックタイピングでコストを削減する • 継承によって振る舞いを獲得する • その他
© - BASE, Inc. 参加者の感想 • クラスとその依存関係の管理という話の中から実 Webサービスのどこにどう当てはめれば良いのかイ メージがわかなかった •
特にCakePHP には適⽤が難しい • ライブラリを作るときくらいにしか使えなさそう
© - BASE, Inc. ⾃分の感想 • 以前からOOPを頑張って実践していた(つもりの) ⾃分からすると有⽤だと分かっていた • だけど実Webサービスに適⽤するにはもっと多くの
パーツが必要になることも分かっていた(OOPだけ でも勉強⼤変なのにね
じゃあOOPを実践した 開発ってやつをしてみよう
OOPだけで実際の開発は語れない 開発に必要なもの OOP
© - BASE, Inc. たくさんのものに繋がっている CleanArchitecture XP TDD パタン‧ランゲージ DDD
デザインパターン OOP リファクタリング マイクロサービス
おすすめ!!
© - BASE, Inc. 動くシステムが出来るまでに必要なのはここらへんっぽい • ドメインとコードを関係付ける、ドメインを把握す る(DDD、ユースケース駆動) • ドメインモデルを技術的関⼼事から隔離する
(CleanArchitecture) • ドメインモデルをコードに落とし込む(OOP、デザ インパターン)
どれも勉強するめっちゃ⼤変
でもまあ全部やるか
photos by Rick Cogley https://www.flickr.com/photos/rickcogley/ 飲み会の勢い
© - BASE, Inc. とは⾔え、 • 元々個⼈で勉強してる⼈が3⼈いた ࣗশOOPࢥय़ظ ʮũţŪŸŕŧŒţŝũƄţ…ʢಡΈʣʯ ʮCleanArchitectureԿΘ͔ΒΜʯ
© - BASE, Inc. ⼈がたくさん集まると、知識も集まる • ⼀⼈ひとりが部分領域をカバーしあえば、全体としてある程 度の網羅率が獲得できる • 完璧でなくて良い
• OOPだけでは語れない現実の開発を、語れるだけの知識を ⽤いて具体的な開発を1回やってみるという内容なので、広く て薄い感じで良い • 輪読会してから実践だといつ終わるか分からない
Done is better than perfect.
© - BASE, Inc. 5⼈で開始 @hgsgtk @fumikony @tenkoma @nazonohito @fuubit
photos by Rick Cogley https://www.flickr.com/photos/rickcogley/ 飲み会の勢い
勉強の題材
© - BASE, Inc. 勉強の題材 • アジャイルソフトウェア開発 の奥義 • 18章「給与システムのケース
スタディ」
© - BASE, Inc. • 給与システムのケーススタディ • システム開発の例題として、給与システムの要件と ユースケースが書かれている章 •
本当はその後の章でデザインパターンを使って実装 するための題材 • 要件定義やらユースケース分析などをスキップして いきなり開発をスタートできそうだった
© - BASE, Inc. 要件(というかユーザストーリー) • 従業員の⼀部は時給である。彼らの給与は、従業員レコードが持つフィールド項⽬の ⼀つに登録されている時給をベースに⽀払われる。給与は毎週⾦曜⽇に⽀払われる。 • 従業員の⼀部は固定給である。彼らの給与は⽉末に⽀払われる。⽉給の額は、従業員
レコードのフィールド項⽬の⼀つである。 • 固定給の従業員の⼀部は、営業成績に応じて成功報酬を受ける。彼らは、売上⽇と 売上⾦額を記録したレシートを提出しなければならない。成功報酬額は、彼らの従業 員レコードのフィールド項⽬の⼀つに登録されている。彼らの給与は隔週⾦曜⽇に⽀ 払われる。 • ………(続く)
© - BASE, Inc. ユースケース • 新しい従業員を追加する • 従業員を削除する •
タイムカードの処理を要請する • 売上レシートの処理を要請する • 組合サービス料の処理を要請する • 従業員レコードの詳細を変更する(例:時給や組合費) • 当⽇の給与⽀払い処理を⾛らせる
© - BASE, Inc. ユースケース1:従業員を追加する AddEmpトランザクションは新しい従業員を追加する。このトランザクションには必 ず従業員(Employee)の「登録ID(EmpID)」、「名前(name)」、「住所 (address)」が含まれる。このトランザクションには下記に⽰す3つの形式がある: 別記1:トランザクションが正しい形式で記述されていない場合 トランザクションが正しい形式で記述されていない場合は、エラーメッセージを吐き
出す。エラーメッセージを出⼒するだけで、何も処理は⾏わない。 AddEmp <EmpID> “<name>” “<address>” H <hourly-rate> AddEmp <EmpID> “<name>” “<address>” S <monthly-rate> AddEmp <EmpID> “<name>” “<address>” C <monthly-rate> <commission-rate>
ドメインモデリング
© - BASE, Inc. 付箋紙を使ったドメインモデリング
© - BASE, Inc. ユースケース記述
© - BASE, Inc. ⼯夫したこと • ドメインモデリングのやり⽅はわりと⼿探り • ドメインモデルがどうコードに繋がっていくかを最 短でイメージできるように1ユースケースの実装を最
優先とした • 実装とモデリングを何往復もする覚悟は済ませた
photos by Woody Zuill https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/ モブプログラミング
© - BASE, Inc. モブプログラミングとは • Hunter Industies社で実施されていた取り組み • 3⼈以上で⾏うペアプログラミングみたいなもの
© - BASE, Inc. 参加者のロール • タイピストの役割 • モブがしてくれと頼んだことを理解すること •
モブを信頼し、⾃分では試さないことも試す • モブの役割 • 問題解決につながる論理的ステップを⾒つける⼒になること • モブ全体の理解の⽔準を上げるため貢献すること
先⾏して勉強してたモブが、 その知識の活⽤場所を ⾒つけた場合は、 積極的に⾔語化してもらう
⾔語化
© - BASE, Inc. ⼈は⾔語にできる以上のことを知っている • 物理化学者で哲学者のMichael Polanyi⽈く、⼈は 語れる以上のことを知っている 引⽤元:エンジニアの知的⽣産術
© - BASE, Inc. 抽象的で分かりづらい本
© - BASE, Inc. 曖昧で点と点でしか無い理解 Specificationύλʔϯ υϝΠϯϞσϧ Entity ValueObject ڥք͚ͮΒΕͨ
ίϯςΩετ ⾔語化出来ない ⾔語化出来る Repositoryύλʔϯ ϢϏΩλεݴޠ
© - BASE, Inc. やりたいこと • 先⾏して勉強していた⼈の学びをより深める機会に したい • それ以外の⼈も学びのスタート地点に⽴てるような
学習をしたい
最も効率的な勉強⽅法は、 ⼈に教えること
© - BASE, Inc. ⾔語化し、⼈に教える • ⼈に教えることで⾔語化が強制される • ⾔語化によって以下の効果が期待できる •
⾃分の知識を体系的に整理 • ⾜りなかった知識の発⾒ • 他の⼈からフィードバックがもらえる =>より深い理解へ
© - BASE, Inc. 教えられた⼈は • おそらく⾔語化されてもそんなに理解できない • 書籍だけでも難しい概念なので •
しかし⽬の前には具象となるコードもあるので、コードと のセットによってある程度の理解が出来る • @nrslibさんのボトムアップDDDに近いアプローチ • 本を読んでなくてもこれまでの⾃分の経験と整合性のある 知識に出会えると感動する(かも)
© - BASE, Inc. 学びのプロセス • 情報収集‧モデル化‧検証の繰り返し 引⽤元:エンジニアの知的⽣産術
© - BASE, Inc. 学びのサイクル 情報収集‧体験 抽象化‧モデル化‧パターンの発⾒ 実践検証 モデル構築 (≒⾃分の中の期待)
体験 書籍 モデル 現実
© - BASE, Inc. 参加者のこれまでの課題と解決 • 先⾏して勉強していた⼈:書籍を通してモデルは出来上がりつつある が、検証されていないため正しさを証明できなかった • それ以外の⼈:書籍を通してもハッキリとしたモデルを脳内に作れな
かった =>検証されることで次の学習ステップへ進める =>具体的なコード+⾔語による情報収集から 精度の⾼いモデル構築
参加者の感想
© - BASE, Inc. 参加者の感想 メンバーと共通の⾔語や知識ができたのでよかったです。 ずっとひとりでやっていたので、学ぶ過程で得られる知識の多さや、 気付きの多さに感動しています。 ⾃分の知識を伝えたり、伝えることで、知識が深まったりしてよいです。 参加者各⼈の⾔語化をフックに、⾃分の中で違う概念とつながり、「あっということはあれはこ
う考えられるのでは」という思考の深みを掘り下げる機会になりました。 ⾔語化した結果を踏まえて、実際のコードベース内でOOPを実践しました。CakePHP の中でや るのはそれなりにフレームワークといかに付き合う必要があるかという考えを深めるきっかけに もなりよかったです ひとの操作を⾒るのはおもろい 仕事でアプリケーション開発したことがほとんどないので、ドメインモデリングみたいなことを 考えたことがそもそもないな みんなの⾔語化能⼒が⾼い ※SRE
モブプロ駆動学習
© - BASE, Inc. モブプロ駆動学習(造語) • みんなで同じコードに向き合う • コードが問題に衝突するたび書籍の知識を使⽤し、 参加者の学習のサイクルが回る
• 先⾏者は⾔語化とコーディングによるモデル検証 • それ以外の⼈はコードとセットになった情報収集と モデル化が促進される
© - BASE, Inc. 課題 • 先⾏者ばかりが話をしてしまうことが多い • スケールしない(たぶん5⼈までが限界) •
たぶんその分野である程度学習済みの⼈がいないと 成⽴しない
© - BASE, Inc. 課題 • 参加者が互いに信頼してないと成⽴しない(重要) • 曖昧な知識のまま実践している、という前提でやって いるのでお互い技術的な弱みを⾒せあっている状態
• ⼈の気持ちや状況を汲み取らない⼈が仮に1⼈いるとし たら、それだけ全てが根本から崩壊してしまう • 今はいません
ご清聴 ありがとうございました!
We are hiring!!!