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

その設計つながってますか?

 その設計つながってますか?

2020/6/18の社内勉強会(Techtalk)発表資料

Naofumi Yasuba

June 18, 2020
Tweet

Other Decks in Programming

Transcript

  1. 1 ⾃⼰紹介・経歴 Naofumi Yasuba 株式会社GxP 取締役/開発本部⻑/VPoE/IT Architect 社内PJのリーダー ・要求分析/基本設計 ・業務フロー

    ・データモデリング ・総合テスト 前職 GxP エンジニア ・Java/Spring ・アジャイル開発 ・オブジェクト指向 ・ドメインモデリング (DDD) アーキテクトとか マネージャーとか ・AWS/GCP/Salesforce ・アーキテクチャ ・CI/CD ・組織運営など何でも
  2. 26 番号をふる u ドキュメントやコンポーネントに⼀意な番号を割り振る • 仕様書ファイルをソートして整理できる • 表記ゆれによる間違いを防⽌ ‒ 顧客情報参照、会員詳細参照など

    • サービス名などビジネス都合の変更にも追随 番号を ふる Step1 IF仕様書_A01_顧客参照.xls IF仕様書_A02_顧客詳細参照.xls IF仕様書_B01_顧客情報更新.xls : :
  3. 28 標準化 u ⼀般的な記法を採⽤する • UML、ER図、BPMNなど。ドロアーツールに対応しているものも多い ‒ astah, EA, gliffy,

    draw.io, pluntUML, A5erなど • 新規メンバーにとっても理解しやすい 番号を ふる Step1 標準化 システム 〇〇する ××する ユースケース図 アクタ シーケンス図 ER図 ユーザ システム システム ◦◦テーブル id name : ××テーブル id name :
  4. 30 レイヤーを表現 u 粒度をあわせ、レイヤーを分けて表現する • 設計書上で表現する粒度は統⼀する。特定の箇所を細かく書きたい場合は レイヤーの違う別の設計書に表現をする • 全体像を俯瞰してみるための資料としても活⽤できる 番号を

    ふる Step1 標準化 レイヤー を表現 Step2 システム システム構成図 ユーザ IF⼀覧 ID | 機能名 ----+------- A01 | 顧客参照 A02 | 顧客詳細参照 B01 | 顧客情報更新 IF仕様書_A01_顧客参照 IF仕様書 IF仕様書_A02_顧客詳細参照 〇〇アプリ システム構成図詳細 ××バッチ ××バッチ 抽出処理 ロード処理
  5. 31 関連を作る u 設計図間の関連を明確にする • 例えば、何かの状態をDB更新する処理については、 (1)ユースケース図、(2)状態遷移図、 (3)機能仕様書、 (4)データ更新仕様/データマッピング表 などを番号で紐付けて管理する

    番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る システム 〇〇する ××する ユースケース図 アクタ 完了 キャンセル 状態遷移図 処理中 機能仕様書 ××機能 1. ・・・ 2. ・・・・・ 3. ・・・ データ更新仕様 △△テーブル No カラム名 ◦◦する ××する 備考 1 id - - 2 name - - 3 ・・ “1” “2” 4 ・・ - システム⽇付 条件 処理
  6. 33 ⽤語を統⼀する u 業務的な⽤語の意味・使い⽅を定義する • 関係者間で⽤語の意味がずれると、後々⼤きなバグにつながる • 例)携帯電話の契約で「契約開始⽇」とはいつのことか ‒ 契約を申し込んだ⽇?申込が受け付けられた⽇?

    ‒ (⽉単位で料⾦が発⽣するのであれば)料⾦が発⽣する翌⽉1⽇? ‒ 携帯電話⾃体の「契約開始⽇」とオプションサービスの「契約開始⽇」 では意味が違うケースもある。⽂脈を読んで判断する必要がある。 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3
  7. 34 WHYをまとめる u 要件や機能だけではなく、その背景(=WHY)を確認する • ⾔われたことだけを実現していても「顧客が本当に欲しかったもの」は ⾒つからない。その背景となる業務を理解しておく必要がある • 背景や設計思想は各設計書に⾔語化して残しておく 番号を

    ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる ××機能 1. ・・・ 2. ・・・・・ 3. ・・・ 機能仕様書 システム ユーザ 〇〇アプリ ××バッチ 機能仕様書 ◦◦を考慮して、 ××の構成とする ◦◦という案も検討したが、 ××の理由で断念した
  8. 36 設計図を⾒直す アプリ u コードの構造をもとに設計図を⾒直していく • アプリケーション内の実装レベル構造と設計書の単位を⼀致させる • 例) 番号を

    ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 プレゼン テーション層 ビジネス ロジック層 データ アクセス層 機能仕様書 IF仕様書 データ更新仕様 【設計】 【実装】
  9. 37 設計からコード⽣成 u 標準化したフォーマットを使ってコードも⾃動⽣成する • フォーマットの制約に従う必要があるが、品質が安定する • コードと同様に設計ドキュメントも出⼒できることも多い • 例)OpenAPIでのModelオブジェクト⽣成、A5erでのDDL⽣成など

    番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 Viewer /Editor 設計書ファイル コード⽣成 ツール 開発者 コード
  10. 38 設計からコード⽣成 u 例)OpenAPI • APIドキュメントの記法をyamlにて標準化 • OpenAPI Generatorにてドキュメント/コード⽣成が可能に 番号を

    ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成
  11. 40 業務⽤語でコード化 u 業務⽤語をそのまま実装コードにする • 例)1週間より⼤きい ‒ 「8⽇以上」と変換しない ‒ 「1週間」という単位や、「より⼤きい」に業務的な意味がある可能性がある

    • 実装コードとしてはいずれも正しいが、業務的な意味との⼀致しているか を突き詰めることで、要件と実装がつながっていく 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5
  12. 41 業務⽤語でコード化 u 業務⽤語をそのまま実装コードにする(再) • 例)申込区分が”1” ? ‒ 何を判定しているのかが読み取りにくい •

    「新規申込の場合に」だとするとこうなる ‒ コードの可読性が向上する ‒ まずは業務ロジックのメソッド抽出で リファクタリング 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 entity.getOrderType().equals(“1”) entity.isNewOrder()
  13. 42 責務を考える u どのクラスがどの業務ロジックを持つべきか考える(責務) • 業務をそのまま実装コードに落としていくと、サービスロジックに 業務ロジックが散らばってしまう • クラスが持つ責務を意識して、散らばった業務ロジックを整理する ⇒

    業務の関係性を整理することにつながる(ドメインモデリング) ‒ アプリケーション内でのオブジェクトの構造が 重要になるため、オブジェクト図をベースに 考えると整理しやすい 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える ドメインモデル ◦◦ドメイン ××ドメイン id name : id name :
  14. 43 責務を考える u まずはデータと振る舞いをセットで考える • データを保持するオブジェクトから gettterを⽤いてデータを取得している のはコードの不吉な臭い • Entityの責務であるべきロジックを

    外に出してしまっている可能性がある 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える entity.getOrderType().equals(“1”) entity.isNewOrder()
  15. 45 RDRAのアプローチ u RDRA(Relationship Driven Requirement Analysis) • 軽く柔軟で精度の⾼いモデルベース要件定義⼿法 u

    4つのレイヤーで段階的にシステムを分析・設計する • システム価値 • システム外部環境 • システム境界 • システム 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える
  16. 46 RDRAのアプローチ u 設計図間の関連を重視し、 システム価値~システム をつなげる • 関連を上位⽅向にたどる ことで根拠が明確になる •

    影響範囲の特定も容易に 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える
  17. 48 DDDのアプローチ u DDD(Domain Driven Design)ドメイン駆動設計 • ドメイン(業務領域)エキスパートと開発者が共通⾔語を⽤いて作成した ドメインのモデルをもとに、継続的にソフトウェアを開発する設計⼿法 •

    「業務をどのように捉えてモデル化するか」という戦略的設計と 「モデルをどのように実装に落とすか」という戦術的設計がある • DDDに取り組むということは、全員業務を理解する必要があるということ ‒ 業務を知らない実装者は全く⼿が動かなくなる 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える
  18. 49 DDDのアプローチ u 顧客と共通の⾔語を使い、ドメインモデルを育てる • ドメインエキスパートと開発者で共通の⾔語(=ユビキタス⾔語)を使う • 業務の境界を適切に設定し、区切られた境界ごとにドメインモデリング を⾏う •

    業務の変化とともに継続的にモデルを育てる 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える 戦略的設計
  19. 50 DDDのアプローチ u 実装技術はオブジェクト指向がベース • クラスに適切な責務を持たせ、データと振る舞いを 1つにすることで、コードの可読性・保守性を上げる • Howとして参考にできるものは⾊々あるが、正解はない。 ‒

    値オブジェクト、エンティティ、リポジトリ、アプリケーションサービスなど 番号を ふる Step1 標準化 レイヤー を表現 Step2 関連を 作る ⽤語を 統⼀ Step3 WHYを まとめる 設計図を ⾒直す Step4 設計から コード⽣成 業務⽤語で コード化 Step5 責務を 考える 戦術的設計
  20. 52 まとめ 設計は「システムの仕様や構造などを決定する⼯程」 正しく設計すると、 設計を通して、要件と実装がつながっているはず これらの考え⽅をもとに、保守性の⾼いシステム開発を 番号を ふる Step1 設計の質を上げる

    標準化 レイヤー を表現 Step2 設計と設計をつなげる 関連を 作る ⽤語を 統⼀ Step3 要求と設計をつなげる WHYを まとめる 設計図を ⾒直す Step4 設計と実装をつなげる 設計から コード⽣成 業務⽤語で コード化 Step5 全てがつながる 責務を 考える