ドメイン駆動設計入門 読了後メモ

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

来年度はスクラッチ開発が予定されているので、手に取った。ちなみにいわゆる「DDD本」は挫折して本棚でほこりをかぶっております。DDD本が出てから久しい。みんなこの程度の知識は持っているのだろうか。。。

主にRails（Djangoでも同じ話だな）での開発を念頭に読んで、気になった点を五月雨に書きます。

Chapter 2. 値オブジェクト

所感

静的型な処理系であれば誤った代入も防げるし、ロジックは集約できるし、価値は理解できるんだけど、ORMと相性が悪そうだなーとは思った。どうしてんだろうな。

Chapter 4. ドメインサービス

所感

各機能に必ずドメインサービスを作りましょうみたいなSIerな考え方だと小規模サービスではかなり窮屈で開発効率が悪くなりそう。 基本的にはモデルに業務ロジックを集約しつつ、モデルをまたがるような処理はドメインサービスに書くのが良さそう。

さすがにコントローラーに長大なロジックを書くことはないんだけど、モデルは大きくなりがちだと思う。理由としては以下が挙げられる。

• DBの正規化が不足していてフィールドが多すぎる
• モデルにまたがった処理が書かれている

後者の場合はドメインサービスの概念を導入してやるとうまくいくんでしょう。

「業務を表現したものではなく、アプリケーションを作るために必要なのであれば、アプリケーションサービスに書くべき」とのこと。メール送信とかはどうなんだろうな。

Chapter 5. リポジトリ

データの永続化を担当。

所感

Railsだとアクティブレコードがあるから不要なようにも思った。

Chapter 6. アプリケーションサービス

ユースケースを実現するためのもの。

所感

MVCアーキテクチャのコントローラーか、バッチ処理のエントリーポイントかな。

アプリケーションサービスがドメインの振る舞いを呼び出せてしまうと、各所にロジックが散らばってしまうので、データを詰め替えるべきとの主張だった。大規模アーキテクチャにありがちなルールだなぁ。

6.4. 凝集度

すべてのインスタンス変数はすべてのメソッドで使われるべき。一部のメソッドでしか使われない変数があるのであれば、クラスとして切り出すべき。

所感

あまり考えられていなかったので、意識したい。モデルやコントローラーのクラスは凝集度が低くなりがちだとは思う。

Chapter 7. 依存関係のコントロール

本来、DBアクセスなどの低レベルモジュールに高レベルモジュールが影響を受けるべきではない。永続化方法はドメインに関係がないはずである。インターフェースを宣言し、低レベルのモジュールはそのインターフェースに合わせて実装することで、依存関係を切り離すことができる。

ここで問題になるのが実装クラスをどうやって作るかだが、DI Containerを使うと良い。

所感

例示されたケースだと、リポジトリ入れ替え可能になるのでテストが楽になるよ、とのことだったが、Railsの場合は本物のDBに向かってテストを実行して大きな問題は感じていない。。。

Chapter 9. ファクトリ

ただ漫然とnewするのではなく、ファクトリを導入すべきか検討する習慣をつけるべき。

所感

これはまあおっしゃるとおりだと思った。

Chapter 12. 集約

集約の外部から教会の内部のオブジェクトを操作してはいけない。集約を操作するための直接のインターフェースとなるオブジェクトは集約ルート（Aggregate Root）と呼ばれるオブジェクトに限定される。

所感

自分の想像していた「集約」とは違った。集約ルートの考え方は良いと思った。ただの代入であっても、それにどんな業務的な意味があるのか、あるのであればメソッドにくくることを検討する習慣を持ちたい。

おしまい

Railsだったらどうするかなーと考えながら読んだ。大前提としてドメイン駆動設計をちゃんとやらなければいけないケースでは静的型が必要で、Railsはドメイン駆動設計には不向きなんだろうと思う。

RubyやPythonなどの動的型付け言語に慣れ切ってしまったところにこの本を読むと、静的型付け言語を使いこなす自信がなくなってくる。ある程度静的型付き言語に慣れた後に読み直すとまた感じ方が違うんだろう。

実際の開発では何らかのWebフレームワークやORMに乗ることになるので、そのフレームワーク流儀に従ったうえでDDDを適用していくんだろう。

「実践ドメイン駆動設計」から学ぶDDDの実装入門 CodeZine Digital First

ミル付きコーヒーメーカー所感

ふたつほど使ったことがあるので、突然ですが所感を書きます。私としては、このふたつなら手入れが楽なパナソニックの方をおすすめします。

シロカ

シロカ 全自動コーヒーメーカー カフェばこ [ガラスサーバー/静音/ミル4段階/コンパクト/豆・粉両対応/蒸らし/タイマー機能] シルバー SC-A351

1年ほど使用。ステンレスフィルター。ガラス製サーバーを落として割ってしまい、スレンレス製サーバーにかえた。

長所

• フィルターの在庫を気にする必要がない
• 見た目がややおしゃれ

短所

• スレンレスフィルターをよく洗うなど、毎回の部品洗浄が面倒
• 連続して淹れるときは、洗った部品を拭いて乾かす必要がある

追記(2021.11.14)：ほぼ毎日1回利用。 ステンレスフィルターは1年半ほどで穴が空いてきたのでフィルターだけ買い替えた。今は在庫切れだな。 バケットの方も1年ほど使って異音がしてきたので買い替えた。こっちはもしかしたら食用グリスとかを塗ればよいのかもしれない。

パナソニック

パナソニック コーヒーメーカー 全自動 ミル付き 沸騰浄水機能 デカフェ豆コース搭載 ブラック NC-A57-K

10年近く使用。ミルが動いた時に異音が出るようになって買い替えた。

長所

• 掃除が楽。紙フィルターを捨てた後に軽く洗うだけ
• ミル部分は自動洗浄されるため、毎回の掃除は不要

そういえば連続して淹れたい時はどうしてたかな、、、忘れてしまった。ミル部分を乾かしたりはしていなかったと思う。

短所

• 紙フィルターの在庫を気にする必要がある

ミル稼働時の音

シロカの方が小さいような気がするけど、パナソニックの方も今は改良されているかもしれない。どっちにしても集合住宅で早朝深夜に動かすのはちゅうちょするレベルだと思う。

味はどうなのよ

どちらもうまいです。なお参考情報↓

超人的な味覚を保有しておりますため、味噌汁のダシはあってもなくても美味しく頂けます。

— こういち (19) (@koty) February 27, 2021

失敗の科学 読了後メモ

失敗の科学　失敗から学習する組織、学習できない組織

やらかし反省シリーズ。やらかしに関係する本を手に取ってみたが、「やらかしをしないようにする」ではなく「やらかすのは仕方ない。それを今後に活かすことが大事」のような内容だった。

第1章 失敗のマネジメント

妻が医療事故により亡くなってしまった事例。

ミスの再発防止のための仕組みができておらず「調査嫌い」な医療業界と、第三者機関など再発防止の仕組みができている航空業界を（ふたつの業界に環境要因はあり必ずしも医療業界を責められないとフォローしつつ）比較している。そして「間違いを教えてくれるフィードバックがなければ、訓練や経験を何年積んでも何も向上しない」「フィードバックを得る環境を作るために『ミスの報告を処罰しない』」ことを説いている。

所感

• 環境要因もあるとはいえ、医療業界の閉鎖性には暗い気持ちになった。日本だけじゃないんだな。
• ミスの報告を責めないのは大事。障害票に「（直接の）障害起因者」欄を作るとか、障害件数ゼロを目標にする組織にいたことがあったけど、今はどうしてるかな。

第2章 人はウソを隠すのではなく信じ込む

人は自分の過ちを認めるよりも、事実の解釈を変えてしまう。 犯罪捜査にDNA鑑定が使われるまでは、捜査は人の記憶に頼っており多くの冤罪が生まれた。

所感

• 自分が誤っていると分かったときは素直に認められるようでありたい。そうしているつもりだけど結構難しい

第3章 「単純化の罠」から脱出せよ

瀉血（しゃけつ）療法の事例、刑務所訪問の効果の事例などを挙げ、 人は物事を単純化しがちだし単純化されて理解しやすいものを信じやすい。 しかし物事はそれほど単純では無いことが多い。RCTなど客観的な事実をみることが大事と説く。

所感

• 累積淘汰のメカニズムは、例の「遺伝的アルゴリズムで最高にエッチな画像を作ろう！」を思い出した。。。
• マッキンゼーのコンサルタントが悪い「完璧主義」の例として出されていて、ちょっとかわいそう

第5章 「犯人探し」バイアスとの闘い

「非難したり訴えたり裁判にかけたりすれば、相手は責任感を強く持つようになると思い込んだままでいいのか、ということだ。今のところそれで説明責任が強化されたという証拠はひとつも出ていない」

所感

まったくそのとおり。。。

第6章 究極の成果をもたらすマインドセット

「個人でも組織でも、失敗に真正面から取り組めば成長できるが、逃げれば何も学べない」

所感

まったくそのとおり。。。

終章 失敗と人類の進化

「子どもたちの心に、失敗は恥ずかしいものでも汚らわしいものでもなく、学習の支えになるものだと刻み付けなければならない。」

所感

これは日々言っていきたい。

最後に

ということで、「やらかし」を気をつけはせよ恐れずに生きたいと思ったのだった。

私って、ADHD脳!? 読了後メモ

最近公私共に大きめの「やらかし」をしていたので、手に取った。何かを解決するわけではないけれど、これまで感じていた生きづらさの原因が見える化されて納得感（？）は得られた。

仕事＆生活の「困った！」がなくなる マンガでわかる　私って、ADHD脳!? (大和出版)

「片付けられない」以外は「注意力散漫」「忘れ物、失くし物が多い」「並行作業が苦手」「決まった手順に沿って作業するのが苦手」など心当たりがかなりあり、程度は分からんけど多少なりとも注意欠陥障害に該当するのだと思う。 これまでいろいろやらかしをしてきて、どうして自分は出来ないんだと悩むことがあったが、これも個性だと思って受け入れるしかないんだろう。 もちろん、やらかさないように努力できるところはしないといけないが。。。注意書きとか予定とか入れててもそもそも注意書きや予定をを見なかったりするんだよな。

それでも、周りにご迷惑をかけつつもここまで生きてこれたから、この先も何とかなるでしょう。

漫画で分かりやすいので、似たようなお悩みの方、うっかり者のフォローばかりしている方、おすすめです。

ローカルプロキシで、Chromeへのレスポンスを編集する（Mac OS BigSur）

やりたいこと

背景は聞かないでください。

• 特定のサイトにアクセスした時に
• 「本番サイトです！」とHTMLに表示

方針としては、ローカルプロキシを立てて特定のサイトの場合だけ当該プロキシを経由、プロキシでレスポンスを編集することを考えた。

ローカルプロキシ

GUIを備えたプロキシもあるようだが、導入がお手軽そうだったmitmproxyというのを使ってみた。

インストール

brew install mitmproxy

いったん起動する

mitmproxy

この状態で、プロキシ経由で証明書をダウンロードする

curl -x 127.0.0.1:8080 'http://mitm.it/cert/pem' > /tmp/mitm.pem

証明書をMacのKeyChainに登録し、Trustする。

タグ挿入スクリプト

BeautifulSoupを使うので入れておく。よく分からんがmitmproxy独自のpython仮想環境がある模様。

/usr/local/opt/mitmproxy/libexec/bin/pip install beautifulsoup4

pythonコードを書く。text/html のレスポンスにタグを挿入する。

import os
from bs4 import BeautifulSoup
from mitmproxy import http

class Injector:

    def response(self, flow: http.HTTPFlow) -> None:
        if flow.response.headers.get("content-type") and flow.response.headers.get("content-type").find("text/html") != -1:
            html = BeautifulSoup(flow.response.content, "html.parser")
            if html.body:
                tag = html.new_tag("span", id="mitmproxy", style="color: red;")
                tag.string = '本番サイトです！！！'
                html.body.insert(0, tag)
                flow.response.content = str(html).encode("utf8")
addons = [Injector()]

書いたスクリプトを指定して、起動しておく

mitmdump -s inject_alert.py

Chromeの設定

Chrome extensionをインストールする。 chrome.google.com

proxyの設定

auto switchの設定

最後に、extensionのアイコンから auto switch を選択する。

大成功の図

なんというか、そもそもこんなことをする必要に迫られたくない。

参考サイト

• mitmproxyを使った快適プロキシ生活 - Repro Tech Blog
• macOS 10.14 Mojave 以降で pac ファイルを使って proxy の設定を行いたいけど出来なかった話 - Qiita
• mitmproxy + curl で ssl通信のテスト - Qiita

失敗の科学　失敗から学習する組織、学習できない組織

「モノリスからマイクロサービスへ」読了後メモ

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

• マイクロサービスに分割されていることで、一部分だけ新しい技術で作り替えやすくなる。これは顧客にとって良い結果を提供する意外にも新しい技術を習得することで開発者の満足にもつながる。
• 分解しやすさ、分解による利益の2軸で分解する機能の候補を絞る
• 一発で分解するのではなく、段階的にリライトを繰り返す

4章の「データベースを分割する」ではデータベースリファクタリングで出てきた話題と割と共通していた。まずはトリガーやデータ更新時、日時バッチ等で新旧両方のDBに更新をかけ、徐々に切り離していくっていう辺りが。

データベース・リファクタリング

トランザクションをかけられない場合にどうデータの整合性を維持するか

2フェーズコミット、オーケストレーションベースのサーガ、コレオグラフィベースのサーガなどが紹介されていたが、どれも私が関わっているシステムには過剰に感じた。保守できる気がしない。

ロールバック用のロジックを用意しておくのが現実的である。

マイクロサービス間の依存関係をどう管理していくか

現実のシステムでも徐々にシステム間連携が増えてきている。何らかの方法で依存関係を見える化しておかないと、ある改修が意図しない箇所に影響してしまうことが先々ありそうな気がする。 サービスメッシュてのが紹介されていたが、これがいいんだろうか。。。

マイノリティであることの不利益を人生で初めて実感した話

通っていたジムの営業時間が縮小して非常に使いづらくなってしまった。 これまでは朝7時から開いていたので、息子を保育園に送った帰りに泳いでから仕事できた。 しかし今後は10時から営業となった。夕方も17時に閉まってしまう。 サラリーマンの私にいったいいつ泳げというのか。 さらには、コーチがやってくれるレッスンも縮小されてしまった。

この件の記事が新聞に載っていて「利用者の8割は高齢者」だそうだ。 今後は主たる利用者にターゲットを絞って営業するとのこと。 つまり少数派である現役世代はスコープ外となったわけだ。 このご時世でスポーツジムは経営が厳しくなり、生きる道をどうにか探した結果で仕方のないことだと思う。 しかし仕方のないと理解はするものの、子どもたちがスイミングを卒業したらサヨウナラで彼らが就職後に水泳を続ける場所は提供せんなどという焼き畑みたいなことをしていていいんだろうか。中長期的に理念を追うことは忘れないでほしい。

これまで何度か人と違う選択をしてきてマイノリティ側になることが多かったものの不利益を被ったことはなかった。 それが今回マイノリティであることの不利益を初めて経験している。

特に結論は無い。あまりネガティブなことは書きたく無いんだけど、今のお気持ちを記録しておく。