Upgrade to Pro — share decks privately, control downloads, hide ads and more …

オブジェクト指向を知らないメンバーがいる中で、クリーンアーキテクチャを目指した話

Cb89e0f8ac5d98dc1b778aed3ccc7caa?s=47 aharenchi
February 18, 2022
17

 オブジェクト指向を知らないメンバーがいる中で、クリーンアーキテクチャを目指した話

新規プロジェクト開発をした際に、クリーンアーキテクチャを意識して開発を行いました。オブジェクト指向を知らないメンバーもいる中でどのように取り組んだのかについて書いています。

Cb89e0f8ac5d98dc1b778aed3ccc7caa?s=128

aharenchi

February 18, 2022
Tweet

Transcript

  1. オブジェクト指向を知らないメンバーがいる中で、 クリーンアーキテクチャを目指した話 エキサイト株式会社 阿波連 智恵 ドメイン駆動設計もし たい!

  2. この発表の目的 それぞれの理想の設計を試せそうな機会があった場合に メンバーレベルや自分のスキルに自信がない場合でも諦めず、 取り組めるように挑戦の後押しをしたい。

  3. 注意 • 実装方法等の詳しい話がありません。 • 発表上、省略して説明している部分があります。 疑問点等ありましたら、ご連絡ください。 あはれんさん(@yu12co_mm)

  4. 4 目指すもの:クリーンアーキテクチャ 目的 「求められるシステムを構築・保守するために必要な人材を最小 限に抑えること」 ざっくり説明 関心事の分離、疎結合をし、 依存関係を一方方向にする というルールを実現するためのアーキテクチャの一例 引用:Clean

    Architecture    達人に学ぶソフトウェアの構造と設計
  5. 5 目指すもの:クリーンアーキテクチャ 実現したいこと • 関心事の分離 ビジネスルール、表示方法、データの保存方法などそれぞれの関心事を分けること • 疎結合 それぞれが密に結合していたら変更しづらいので、疎結合にする •

    依存関係を一方方向にする 変更されやすいものに依存していたら変更が多くなって大変なので、変更されにくいものに向 かって依存しする
  6. 6 目指すもの:ドメイン駆動設計 目的 「ビジネスの問題を解決するためにビジネスの理解を進 め、ビジネスとコードを結びつけて継続的に改良できるソフ トウェアを作る」 ざっくり説明 開発者だけでなく、 開発する対象(ドメイン)に詳しいドメインエキスパート と協力してドメインモデルの探求を繰り返し、

    開発することを実現するためのパターンの一例 引用:エリック・エヴァンスのドメイン駆動設計
  7. 7 目指すもの:ドメイン駆動設計 • ドメインとは ◦ ソフトウェアで問題解決しようとする対象領域 ◦ 占いサービスなら「占い」、衣服購入サイトなら「衣服」等がドメインになる。 • ドメインモデル

    ◦ ドメインを解決するためのモデル ◦ 例えば、占いならば「占い師、占術」などの概念がモデルになりうる。 • ドメインオブジェクト ◦ ドメインモデルをソフトウェアで動作するモジュールとして表現したもの
  8. 8 目指すもの:ドメイン駆動設計 ドメイン駆動設計のやりたいこと ドメイン ドメイン モデル ドメイン オブジェクト ドメインについて 理解を深め

    モデルを改善する モデルを ソフトウェア に反映する 問題 解決 ドメインについて理解を深めモデルを継続的に改善し、 そのモデルを継続的にソフトウェアに反映される
  9. 9 理想の設計を目指すとは 必要な人材を最小限に抑えながら ビジネスとコードを結びつけて 継続的に改良できるソフトウェアを作る 求められるシステムを 構築・保守するために 必要な人材を最小限に抑えること ビジネスの問題を解決するために ビジネスの理解を進め、

    ビジネスとコードを結びつけて 継続的に改良できるソフトウェアを作る クリーンアーキテクチャの目的 ドメイン駆動設計の目的
  10. 理想の設計を 目指した者たちの話

  11. プロジェクトのサービス概要 11 ユーザと占い師がZoomを利用して占い体験をすることができるサービス ▼ 開発するWebサービス 1. ユーザ側のWebサービス 2. 占い師が利用するWebサービス 3.

    運営が利用するWebサービス
  12. プロジェクトメンバー 12 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 7ヶ月 8ヶ月

    経験者 知っている 知らない メ イ ン ヘ ル プ 初期メンバー3名は知識あり。 メインで開発するメンバーには経験者はいなかった。 ▼ メンバーのドメイン駆動設計・クリーンアーキテクチャのレベル
  13. プロジェクトメンバー 13 ▼ 懸念点 • 経験者が少ない ◦ 経験者不足で実装ができない可能性がある • リモートワーク

    ◦ 知識共有やコミュニケーションの難しさ • 途中参加するメンバースキルが参加するまで分からない ◦ 初めて一緒にお仕事する方が途中参加するので、メンバースキルが参加するまで分 からず、理想の設計で実装できない可能がある
  14. 理想の設計を目指すことを決定 14 エンジニアとして、長年利用できるサービスを提供したい。 そのためにも、求められるシステムを保守しやすい状態で開発していきたい 。 懸念点もあるが、理想の設計を目指さない理由にはならない。 懸念点を受け入れながら取り組むことを決定。

  15. 15 1. 目的の設定 2. ディレクトリ構成の決定 3. 環境整備、サンプルコードの用意 4. 参考教材の用意 やったこと:プロジェクト開始当初

  16. 16 1. 目的の設定 チーム内で目的意識の共通化、何か選択する際に判断材料とするために設定。 経験者にアドバイスをもらい、どういう点に注意したほうがいいか聞きながら 初期メンバーで決定。 やったこと:プロジェクト開始当初 設計指針:「仕様を理解しやすく開発がしやすい構成を目指す」 1. 責務が広くてテストもしにくい神リポジトリインターフェースをやめる

    2. ドメインオブジェクトに仕様を集約させ、把握を容易にする(ドメインモデル貧血症を避ける) 3. カバレッジ基準がバラバラでテストを書くたびに悩み、開発しづらい体制を解消する
  17. 17 やったこと:プロジェクト開始当初 2. ディレクトリ構成の決定 ディレクトリ構成が実装者によって 差異がでないように基本形を決定。 経験者に、 ディレクトリ構成を考えてもらい、 初期メンバーで話し合って決定。 ※ フレームワークはLaravelを利用

  18. 18 やったこと:プロジェクト開始当初 3.  環境整備、サンプルコードの用意 慣れていないメンバーも開発できるようにするために用意。 経験者の協力のもと、 QAツールやデバッグツール、テストが実施できる開発環境の用意。  → メンバーのレベル差によるコード品質の差をカバーできる状態を実現 経験者の協力のもと、

    文章の表示・投稿・更新をするサンプルページを作成。  → 慣れていないメンバーもアーキテクチャに沿ったコードの書き方、テストの書き方を分かる状態を実 現
  19. 19 やったこと:プロジェクト開始当初 3.  環境整備、サンプルコードの用意 新規プロジェクトにおける環境整備について、以下のスライドがおすすめ。 引用:https://speakerdeck.com/ohshige/xin-gui-puroziekutofalsekai-fa-sutatoqian-niyatuteokubekihuan-jing-zheng-bei-tati-ee18fb54-2e4b-40ad-bb64-dc61e588b1ad

  20. 20 やったこと:プロジェクト開始当初 4.  参考教材の用意 引用:https://github.com/little-hands/ddd-q-and-a 引用:ドメイン駆動設計    モデリング /実装ガイド 引用:ドメイン駆動設計入門 ボトムアップでわかる!

       ドメイン駆動設計の基本 初めてドメイン駆動設計を 学ぶ際にオススメ! 実装パターンから解説するので、難 しい概念を理解しやすい。 ドメイン駆動設計を 体系的に学べつつ、 Q&Aでより実践的な疑問を 先取りできる。 実際に実装して「難しい」 と感じた方に、オススメ! 実装上の悩みを投稿可能。 Q&A形式で悩みを解決!
  21. 21 準備完了! これでプロジェクトも順調に進む!                              と思いきや.....

  22. 22 プロジェクトが始まって生まれた課題 1. それぞれのドメインオブジェクトを作ってしまう問題 複数人で同じドメインモデルに関わる箇所を開発する上で、 共通認識のドメインモデルがないと、それぞれのドメインオブジェクトを生み出す Aさん ユーザ情報一覧 ページ作成 Bさん

    ユーザの情報更新 ページ作成 ユーザ (ドメイン オブジェクト) ユーザ (ドメイン オブジェクト) 衝突
  23. 23 プロジェクトが始まって生まれた課題 2. サンプルコードのパターン外になると全然違う設計になる問題 設計意図を伝えきれていないので、それぞれの設計になる。 3. 慣れていないメンバーに教える時間が足りない問題 メンバーの半数以上が、知らないメンバーなので教える時間が足りない。

  24. 24 やったこと:プロジェクトの課題への対策 1. それぞれのドメインオブジェクトを作ってしまう問題 ドメインオブジェクト定義シートを用意 ドメイン駆動設計をするにはドメインの共通認識が大事。 ドメインオブジェクトを書き出したシートを共有し、 そのシートを元にドメインオブジェクトをブラッシュアップしていく。 対策

  25. 25 やったこと:プロジェクトの課題への対策 2. サンプルコードのパターン外になると全然違う設計になる問題 情報共有・ペアプロ(ペアプログラミング) 該当のパターンの設計について解説している本や記事の共有。 情報共有で意図が伝わらない場合は、ペアプロで設計意図を伝える。 対策

  26. 26 やったこと:プロジェクトの課題への対策 3. 慣れていないメンバーに教える時間が足りない問題 クリーンアーキテクチャを目指すソフトウェアを絞る ユーザ用のWebサービスのみクリーンアーキテクチャを目指すことを決定。 占い師、運営用のWebサービスは、テストとディレクトリ構成は守る方針で決定。 ユーザ用のWebサービスの選定理由:  仕様の変更が多く、ロジックも複雑になることが見込まれたため 対策

  27. やったこと:まとめ 27 1. 目的の設定 2. ディレクトリ構成の決定 3. 環境整備、サンプルコードの用意 4. 参考教材の用意

    5. ドメインオブジェクト定義シートを用意 6. 情報共有・ペアプロ(ペアプログラミング) 7. クリーンアーキテクチャを目指すソフトウェアを絞る
  28. 28 懸念点と結果 懸念点 結果 経験者が少ない ◦ サンプルコードと情報共有・ペアプロで、 未経験者にもフォロー可能。フォローする時間は必要。 リモートワーク ◦

    Slackやチャットツールを使えばコミュニケーション可能 途中参加するメンバースキルが 参加するまで分からない △ 人員のスキルコントロールは難しい。 部分的に、理想の設計を諦める判断も必要あり。
  29. 29 個人的評価 長年サービス運用のためにクリーンアーキテクチャを目指したが、 5ヶ月でサービスクローズしたので、効果を最大限活かせなかった。 △ よくなかったこと • 設計のメリットを活かしきれなかった よかったこと •

    修正が容易であった • エンジニアメンバーの成長に繋がった
  30. まとめ 30 メンバーレベルや自分のスキルに自信がない場合でも 理想の設計を目指して開発はできる! が、100%成功は難しい! この発表を踏み台にして、皆様の開発に活かしてほしい! 俺たちの戦いはこれからだ!!!!