architecture - taka512/memo GitHub Wiki

DDD

アークテクチャ

レイヤードアーキテクチャ

  • エバンス本
  • 上位のレイヤから下位のレイヤを呼び出す。逆はない
  • 上位レイヤは下位レイヤに依存

ユーザインタフェース層(プレゼンテーション層)

ユーザとの接点

アプリケーション層

ユースケースを表現

ドメイン層

ビジネス業務を表現

ヘキサゴナルアーキティチャ

  • 実践DDD本
  • アダプタ
  • ポート

クリーンアーキティチャ

  • クリーンアーキテクチャ本
  • 特徴
    • 複雑
  • へキサゴナルアーキテクチャと似ていおり、違いは実装方法が明示されているのがクリーンアーキテクチャ
  • エンティティの概念がDDDと異なる。ドメインオブジェクトに近い概念

オニオンアーキテクチャ

  • 特徴
    • シンプル
  • 構成
    • プレゼンテーション層
      • 例: コントローラ
    • アプリケーションサービス層
      • ユースケースクラス
    • ドメイン層
      • エンティティ
      • リポジトリのIF
      • ドメインサービス
    • インフラ層
      • リポジトリ

アンチパターン

レポジトリ

  • 子テーブルに対して沢山Repositoryを作る
    • 集約で対応
  • ドメインのルールがアプリに染み出す
    • しょうがない面もある
    • 性能と相談しつつ
    • indexショットガンを避ける
  • CQS
  • CQRS

設計

継承

  • 継承より委譲

ポリモーフィズム(多態性)

単一責任の原則(SRP)

  • モジュールはたった一つのアクターに責任を負うべきである
  • アクターの異なるコードは分割すべき
  • 凝集性が高まる
  • クラスを変更する理由が複数あるべきでない

オープン・クローズドの原則(OCP)

  • 拡張に対して開いて、修正に対して閉じる
  • 既存の成果物に対して影響を与えずに変更できるようにすべき
  • 上位レベルのコンポーネントは下位レベルのコンポーネントで変更があっても影響を受けないようにする

リスコフの置換原則(LSP)

  • 基本クラスをサブクラスに入れ替えても問題なく動かなけらばならない

インタフェース分離の原則(ISP)

  • クライアントは使わないインタフェースの実装を強制されるべきではない

依存関係逆転の原則(DIP)

  • 変化しやすい具象要素に依存してはいけない
  • 変化しやすい具象クラスを継承しない
  • 具象関数をオーバーライドしない

再利用・リソース等価の原則(REP)

  • コンポーネントを形成するクラスやモジュールは凝集性のあるグループでなければならない
  • コンポーネントは一貫するテーマは目的がありそれを共有するモジュールを集めなければならない
  • 一つのコンポーネントを形成するクラスやモジュールはまとめてリリース可能でなければならない

閉鎖性共通の原則(CCP)

  • SRPのコンポーネント版
  • コンポーネントを変更する理由が複数あるべきでない
  • 同じタイミング同じ理由で変更するものはひとまとめにする事。変更のタイミングや理由が異なるものは別々に分けること

全再利用の原則(CRP)

  • コンポーネントのユーザに対して実際に使わないものへ依存を強要してはいけない
  • 一緒に用いられることの多いクラスやモジュールは同じコンポーネントにまとめる
  • コンポーネントに依存するのであればコンポーネントに含まれる全てのクラスるに依存するようにしておきたい
  • 一つのコンポーネントにまとめるクラスはどれも切り離せないものにしておきたい
  • どのクラスをまとめるべきでないか教えてくれる原則

コンウェイの法則

デメテルの法則

YAGNI

DRY

KISS

データベース

  • サロゲートキーをつける
    • 履歴がbigint型、マスター系はint型
  • 日時カラムは「~_at」でdatetime型
    • 作成、更新、削除は「created_at」,「updated_at」,「deleted_at」
  • 日付は「~_date」でdate型
  • 月は「~_month」でdate型で日付は01を指定する