Domain Modelを共有していい感じにプロダクトを作る

PM、デザイナ、フロントエンド、バックエンドがいい感じに協業するための考え方の提案。

Transcript

1. Domain Modelを共有して いい感じにプロダクトを作る 受託開発 TomPenguin karabiner. inc 2023/03/07 最近暖かくて気持ちいいね カラビナテクノロジーという会社で、わがまま言ってフロントエンド やったりバックエンドやったり新規事業やったりなんか色々やってる 人です。仙台で働いてるよ。
2. 目次 2 1. はじめに 2. コンセプト 3. しなかったこと 4. Domain Modelとは 5. ワイヤーフレーム/デザイン 6. デザインシステム 7. フロントエンド 8. GraphQL Schema 9. Domain Modelの進化 10. 良かったこと 11. イマイチなとこ 12. まとめ
3. はじめに 3 • 受託開発（開発期間は3ヶ月くらい） • 納品後も継続的に機能開発をしていく予定の案件 • 参照が中心でそこまで複雑な業務ロジックがない • メンバーはPM、デザイナ(1名)、フロント(1名)、バック(2名) 業務でやってみてうまくいったかも？という話です。 つまりガバガバなので鵜呑みにせず参考程度に聞いてもらえると🙌
4. コンセプト 4 Domain Model を中心として各分野の既存概念とそれっぽくマッピングするこ とで、プロジェクトメンバー間の認識の齟齬、ドメイン知識と実装の乖離を減 らそうという試み。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types かっこよく見えるけど あくまでイメージね！
5. しなかったこと 5 DDDやユースケース駆動設計を参考にしつつ、案件の特性を鑑みて必要最低 限のものだけを取り入れた。 • ユビキタス言語辞典みたいなのはつくらない • ユースケースがどうとかリポジトリがどうとかあまり気にしない • マッピングさせることにこだわりすぎない
6. Domain Modelとは 6 DDDのアレですが、シンプルにシステムで扱う必要最小限の情報を、ビジネス 上で意味のある単位にまとめて名前をつけたものをここではDomain Modelと 読んでる。あってるかわからんごめん。 応募者 Applicant ・名前 ・メールアドレス 採用選考 Screening ・選考ステータス ・応募日 面接 Interview ・面接次数 ・日時 こんな雰囲気のゆるいやつを FigJamに書いて共有してました
7. ワイヤーフレーム/デザイン 7 Domain Model を OOUI のオブジェクトにほぼそのままマッピング。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types 参考：オブジェクト指向UIデザイン──使いやすいソフトウェアの原理 (WEB+DB PRESS plusシリーズ) https://amzn.asia/d/44G2TbJ
8. デザインシステム 8 リリース後も継続的な機能開発が想定されていたため、Figmaでatoms, moleculesレベルのみの軽量なデザインシステムを構築した。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types 参考：Atomic Design https://bradfrost.com/blog/post/atomic-web-design/
9. フロントエンド 9 Domain Model を Atomic Design の organisms レベルで対応させたコンポー ネントを実装する。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types
10. GraphQL Schema と Type 10 Domain Model と GraphQL の Schema をほぼそのまま対応させる。 TS の型を Schema から生成し、フロントエンドとバックエンドの双方で利用。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types
11. GraphQL Schema と コンポーネント 11 GraphQLのSchemaはフロントのorganismsレベルのコンポーネントとほぼ対 応するのでマッピングが容易。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types
12. Domain Modelの進化 12 実際にデザインしてみて、実装してみて見つけられた新しい知識は、Domain Modelをメンテして、デザインや型や実装に反映させていった。 Domain Model Atomic Design OOUI GraphQL Schema Application Design Design System & Frontend’s Components Backend & Frontend Types
13. 良かったこと 13 • メンバー間で認識の齟齬がとにかく少なかった • ↑によりコスパがよかった • ドメイン知識と実装の乖離が少ないのでクライアントとの調整も比較的 スムーズ • （特定の条件が重なる必要はあるが）受託案件でもある程度いい感じに 進められる道筋が見えた
14. イマイチなとこ 14 • デザイナ、フロントエンド、バックエンド、それぞれがそれぞれの分野 である程度スキルを持っている必要がある • PMの理解が必要なところ（今回はその辺恵まれていた）
15. まとめ 15 Domain Modelを中心として各分野の既存概念がゆるく繋がりマッピングが 容易になったことで、認識の齟齬による手戻り、ビジネス知識と実装の乖離 が減り、コスパの良さを感じた。受託開発だとスピードを優先させてこの辺 は適当にやりがちだが、まあやりようなんじゃないかと思えた。