2020年4月8日、水曜日。

以前買ったバターケースを使ってないことを思い出してさっそく使う。バターをケースに入れる前に10gずつに等分したのだけれど、これをケースにしまうのが大変だった。外にいようが家にいようが、日常ってのは面白いものだ。

ひきつづき『clean architecture 達人に学ぶソフトウェアの構造と設計』を読む。第Ⅲ部の途中まで。

• 第7章: SRP:単一責任の原則* モジュール（ソース、関数、データをまとめた凝集性のあるもの）はたったひとつのアクターに対して責任を追うべきである* アクターの異なるコードは分割するべきである* 解決策のひとつとして「データを関数から切り離す」戦術がある* 同じクラスを利用せず、アクター別のクラスを用意する* 異なるクラスが増えすぎて収拾がつかない場合にはFacadeパターンを利用する* 切り離す前のクラスに重要な（共通的な）メソッドとFacadeパターンを載せる戦術もある* 単一責任の原則は、関数レベルの原則であり、コンポーネント・アーキテクチャレベルでも単一責任の原則はある（名前は異なる）

• 第8章: OCP:オープン・クローズドの原則* ソフトウェアの振る舞いは、既存の成果物を変更せずに拡張できるようにすべきである* この原則はクラスの設計指針というより、むしろコンポーネントのレベルを考慮したときに重要なものとなる* コンポーネントからコンポーネントへの線（依存）は、すべて一方通行にする* コンポーネントは、「自分自身を変更したときに影響を及ぼしたくないコンポーネント」に対して依存させる* 感想: ここでいう「影響」は実際の処理だけではなく、前述されているデプロイなども含まれているだろう* アプリケーションの中心となる関心事を処理するビジネスルールをふくむコンポーネントは特権的な位置づけを得るべきである* 特権的なコンポーネントは、他のすべてのコンポーネントの変更による変更の必要をなくすようにする

Pythonのパッケージ、モジュールのimportについて。やっとひとつ理解できた。まだ言語化できていないのだけれど、揮発しないうちに頑張って実践してみる…ということでかれこれ4,5時間熱中して株プログラムの依存関係を整理してみた。IDEでもうすこし楽にできればいいのだけれど、とりあえずは全部タイピングして血肉にできた。

このあたりの実装ができるようになると、あらためて設計の難しさに立ち戻ってくる。もう何度か忘れてしまったけれど、もう一度DDDをやりなおそうか。