# 08ex99. Private Note
________________________________________
どこにも参考元がないのだが、筆者が勝手に思っていることを書いているメモ

________________________________________
## DDDとモジュール 2022/03/17

1. DIP/ヘキサゴナル/オニオンなどにおいてドメインは「最上位・他層を参照しない」である
2. では、コンパイラ型言語ならばDLLとして独立させても全く問題ないのではないか？
3. 例えば、Webアプリケーション(フロントSPA-バックエンドAPIを想定)の時
    - バックエンドAPI側は「API定義/URIルーティングおよびアプリケーション層」と「ドメイン」はDLLの分離が可能なはずである

メリット

1. ドメインと非ドメインが不明瞭になる泥団子になることを強制的に防ぐ

________________________________________
## DDDとリファクタリングと強い階層方式 2022/03/25

1. DDDとリファクタリングが恒常的に行われるならば
2. プログラムのフォルダ/namespace階層構造の変更すら容易に行うことが可能なはずである
3. わざわざフォルダとnamaspaceを別々に管理する意義も薄いため、原則一致させる
4. ならば、classの依存関係-ドメインモデルの依存関係-サブシステムの依存関係をそのままフォルダ階層にするべきではないのか？

メリット

1. 依存関係が明瞭
2. モノシリックや成長したモジュールを分割したくなった時、フォルダ単位でみるだけで良く変更しなければならない箇所が明瞭

________________________________________
## 技術的負債の否定 2022/03/25

1. 技術的負債という単語は技術者やプロジェクトの未熟さを覆い隠す
   - 原子炉を建てるのを分かっているのに犬小屋の方法で建て始めるのは、借金ではない。ただの判断ミスだ
   - プロジェクトのルールを破って安易な方法で改修を行うのは、借金ではない。ルール違反だ。違法だ
   - 借金とは、返済期限があるものを指す。プロジェクト計画に返済計画が組み込まれなければならない
   - 枯れたフレームワークを採用し、新しいフレームワークを見送るのは負債と表現するのは適切ではない
2. 技術的負債という単語はDDDのデメリットも覆い隠してしまう
   - 「要件が変わってDDDでは間に合わない」とあなたは真顔で言う気か。なぜ間に合わないのか
3. 技術的負債とは、応急手当の改修や対応によって生まれ、恒久的なリファクタリングや正規の対応によって返済するもののみを指すべきだ
4. トランザクションスクリプトを否定してDDDを肯定しても仕方ない
5. トランザクションスクリプトをDDDに（組織的にも・技術的にも）組み替える手段こそが重要である
   - リファクタリングパターン、レガシーコードの改善など限定的な手段は確立されている
   - 犬小屋を原子炉に建て替える方法が体系化されていないことが問題なのだ
   
________________________________________
## ユーティリティクラスとOOPとDDD 2022/09/02

1. ユーティリティクラスとDDDのServiceクラスを可能な限り避けよ、と似たニュアンスだ
2. ユーティリティクラスはユーティリティでなければならない。ドメイン知識を持っていてはならない
3. 言い換え1：ユーティリティクラスはアプリケーション層で直接呼ばれてはならない
4. 言い換え2：ユーティリティクラスを切り出してOOSとしてGithubにそのまま公開しても問題がないはずだ

________________________________________
## 人類の過ち

1. DOSが区切り文字にバックスラッシュを採用したこと（スラッシュに別の命令が割り当てられていたこと）
2. BOMあり、BOMなしの概念が混在するUTF8（そして多くのBOM付きを認識しないOSS）
3. httpメソッドおけるPUT、PATCH、DELETE。というか、httpメソッドでPOSTと使い分けが困難な動詞を定義しようとしたこと
4. htmlの仕様
5. ES4以前のjavascript
6. Pub/SubのSub。そしてRxでObservableのメンバ名をIsSubscribedToByにしなかったこと