読者です 読者をやめる 読者になる 読者になる

エンジニアリングにはほど遠い

iPhoneアプリとかサイトとかをつくっていくブログです。

読書:ドメイン駆動設計

エンティティ

  • 同一性をもつオブジェクトを表現する

値オブジェクト

  • 同一性ではなく物事の特徴を表現する。"どれ"ではなく"何"であるか

モジュール

  • 単一の概念のオブジェクトをまとめる
    この考えで考えるとRailsでmodelディレクトリ以下にphysical logicalとか切るのとは反していると思った

集約(AGGREGATES)

  • 複数のエンティティと値オブジェクトをまとめて、そのまとめたもののグローバルな同一性と不変条件のチェックの責務をルートエンティティに持たせる
  • 集約の境界外のオブジェクトは境界内部への参照を持つ事が出来ない。ルートエンティティを経由してアクセスする。Railsでこれをどう表現すべきなんだろう。

ファクトリ(FACTORIES)

  • オブジェクトの生成の際に、その組み立てについて生成物が責任を負わないため
  • 不変条件について ロジックをファクトリが持ったり、生成物に委譲したりする

リポジトリ(REPOSITORIES)

  • データベースからデータを引っ張ってくる為のカプセル化された仕組み?なのかと思った。RailsでいうActiveRecordの様な。
  • 集約ルート以外のオブジェクトにはクローバルにアクセスできないようにするべき。-> RailsActiveRecordもホイホイ呼ぶべきではなく、集約のルートを経て呼び出すべきなのだろう。
  • トランザクション制御はリポジトリではなくクライアントでやるべき。-> 個々の物理モデルを表現したActiveRecordではトランザクションの事は考えない方がいいのかな。

仕様(SPECIFICATION)

よくわからなかった

しなやかな設計

以下に注意する。

  • 副作用の無い関数(SIDE-EFFECT-FREE-FUNCTIONS)
  • 表明(ASSERTIONS)
  • 概念の輪郭(CONCEPTUAL CONTOURS)
  • 独立したクラス(STANDALONE CLASSES)
  • 閉じた操作(CLOSURE OF OPERATIONS)

とりあえず10章まで読んだ

が、難しかったり、さしあたりRailsでの実現方法について調べたいので一旦この本はここまでにしようと思います。 ドメインモデルのリファクタリングの例とか載っていたんですが、難しいしピンとこなかった...。