0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

現場で役立つシステム設計の原則 まとめ

Last updated at Posted at 2021-06-07

備忘のためのメモです。

1.小さくまとめてわかりやすくする

  • オブジェクト指向設計は変更を楽で安全にする工夫
  • コード整理の基本は名前と段落
  • 短いメゾット、小さなクラスを使ってコードを整理する
  • 値オブジェクトでわかりやすく安全にする
  • コレクションオブジェクトで、複雑なロジックを集約して整理する
  • クラス名やメゾット名と業務の用語が一致する程、プログラムの意図がわかりやすくなり、変更が楽で安全になる。

2.場合分けのロジックを整理する

  • 早期リターンやガード節を使うと区分ごとのロジックをわかりやすく整理できる
  • 区分ごとに別クラスに分けると独立性を高めることができる
  • 多態を使うと、区分ごとのロジックをif文/switch文を使わずに記述できる
  • 列挙型(enum)は、叩いをシンプルに記述する仕組み
  • 列挙型を活用すると、区分ごとの業務ロジックをわかりやすく整理して記述できる

3.業務ロジックをわかりやすく整理

  • 変更が大変になるのは、データクラスと昨日クラスを分けるから
  • データクラスを使うと、業務ロジックの重複が増える
  • アプリケーション全体のコードの見通しを良くするためには、データとロジックを一体にする設計を徹底する
  • 業務ロジックは業務データの近くに集める(=ドメインオブジェクト)
  • ドメイン(業務アプリケーションの対象領域)をオブジェクトのモデルとして整理したもの = ドメインモデル
  • ドメインモデルに業務ロジックを集める
  • ドメインモデルは画面やDBの都合から独立させる
  • 他の層では業務的な判断/加工/計算のロジックをドメインモデルに任せることでシンプルでわかりやすい構造になる

4.ドメインモデルの考え方で設計

  • ドメインモデルは業務ロジックをオブジェクト指向で整理する技法
  • データの整理ではなく、業務ロジックの整理
  • 業務の関心事は、ヒト/モノ/コトで整理できる
  • コトを整理の軸にする
  • 起きてよいこと/起きてはいけないことの判断と対応が業務ルール
  • 業務ルールをオブジェクトで表現する一般的なパターンを覚えておくとドメインモデルの設計がやりやすくなる
  • ドメインモデル設計のインプットは業務の言葉の正しい理解
  • 業務の言葉を正しく覚え、正しく使えるようになることが、良いドメインモデル設計に直結する
  • 業務知識をプログラミング言語で体系的に表現したドメインモデルを中核にした業務アプリケーションは、変更が楽で安全になる

5.アプリケーション機能を組み立てる

  • アプリケーション層は、業務処理の進行役であり調整役
  • アプリケーション層のサービスクラスをシンプルに保つことが、システム全体の見通しの良さと、変更のやりやすさにつながる
  • サービスクラスは、様々な関心ごとの交差点になり、ごちゃごちゃしやすい
  • サービスクラスはシンプルに保つための設計の徹底が重要
  • 全体を段階的に組み立てながら設計の改善を続ける
  • 業務的な判断/加工/計算の詳細はドメインモデルに集約する
  • 画面の複合した関心事を持ち込まない
  • そのためにサービスクラスのメゾットを基本処理単位に分解する
  • 必要に応じて複合サービスを提供する
  • データベースのデータ操作を意識しないように分離し隠蔽する

6.データベースの設計とドメインオブジェクト

  • 制約のないデータベースがプロがラムを複雑にする
  • 制約を撤退するとデータ管理がうまくいき、プログラムがわかりやすくなる
  • テーブル設計の基本は3つの制約(NOT NULL制約、一意性制約、外部キー制約)
  • 良いテーブル設計のコツは「コトの記録」の徹底
  • 状態の更新はコトの記録とは独立させる
  • オブジェクトとテーブルは設計の動機ややり方が基本的に異なる
  • オブジェクトとテーブルの設計を独立させやすい仕組みを活用する

7.画面とドメインオブジェクトの設計を連携させる

  • 画面はアプリケーションに複雑さを持ち込む
  • 「何でも画面」は分かりにくい
  • タスクごとの画面に分けて考える
  • 画面とドメインオブジェクトは「利用者の関心事」として一致する
  • 画面とドメインオブジェクトを一致させる改善が、ドメインオブジェクトの設計を洗練させる
  • リリースノート、利用者ガイドなど、多くの関係者が理解し確認できる内容とソフトフェアの設計を一致させることがソフトウェアの変更を楽で安全にする

8.アプリケーション間の連携

  • アプリケーション間の連携が、アプリケーションの価値を高める
  • 連携方法はファイル転送/データベース共有/Web API/非同期メッセージングがある
  • Web APIの利用が広まっている
  • 肥大化したWeb APIは使う側も提供する側も負担が大きい
  • APIの変更を楽で安全にするには、小さなAPIに分ける
  • APIも進化することで価値を生む
  • アプリケーション間を疎結合に連携する非同期メッセージングは今後の有力な選択肢

9.オブジェクト指向の開発プロセス

  • オブジェクト指向の良さを活かすには分析と設計を一体にした開発のやり方が必要
  • 分析工程と設計工程を分割しない
  • 分析と設計を同じ人間が担当する
  • 分析設計の成果はコードで表現する(自己文書化)
  • 更新すべきドキュメントは利用者ガイドや業務マニュアル
  • ソースコードを中心に進捗と品質をマネジメントする
  • 対象業務の理解と生入りに意欲がある技術者を選んで育成する

10.オブジェクト指向設計の学び方と教え方

【学び方】古い習慣から抜け出すためのちょっと過激なコーディング規則

  1. 1つのメソッドにつき、インテンドは1段落まで
  2. else句は使わない
  3. 全てのプリミティブ型と文字列型をラップすること
  4. 1行につきドットは1つまで
  5. 名前は省略しない
  6. 全てのエンティティを小さくすること
  7. 1つのクラスにつきインスタンス変数は2つまでにすること
  8. ファーストクラスコレクションを使用すること
  9. getter、setter、プロパティを使用しないこと
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?