🐷
オブジェクト指向
この記事を元に気になったことを調べた
Stage3:OOPの"4 Primary Principles"と"Paradigm Features"はStage2の部分に当たるClean Architectureを読んだ時に(読書メモはこちら)大体読んだところなので今回はStage3と4の部分で気になったところをみる
モデル駆動デザイン
ドメインモデル
- モデルに処理を集約させると「モデルさえあれば、どこでも同じ処理ができる」という世界を作ることができる。
- データ（Webアプリケーションで扱う概念）の "バリデーション", "状態判定", "状態変更", "デフォルト値設定" をするための実装をする場所
- 例えばSlackを実装する場合、以下がモデルの候補となる。
- ユーザー
- メッセージ
- スレッド
- リアクション
アネミックモデル=ドメインモデル貧血症
anemic・・・貧血に関連するか、貧血に苦しむ様
一見本物のドメインモデルに見え、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているが、オブジェクトにはわずかな振る舞いしかない。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在している。このアンチパターンが根本的に怖いのは、オブジェクト指向設計の基本概念（データと処理を一緒にする）の真逆である。Eric Evans は、素晴らしい著書『Domain Driven Design』の中で、これらのレイヤについて次のようなことを言っています。アプリケーションレイヤ（サービスレイヤのこと）：ソフトウェアが何をしなければいけないかを定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。このレイヤは薄く保たれている
レイヤードアーキテクチャ
ドメイン言語
クラスを不変にする
クラスを不変にした方がいい理由:
→golangで関数よりメソッドで実装した方がいい理由？
「メソッド」はOO言語から特定の型に関連するものとして採用されただけで、「関数」は関数が独立した手続き型言語から採用されたものなのだ。
デザイン原理
継承より合成
go言語はそもそも継承という仕組みはなく合成しかできない
Discussion