エリック・エヴァンスのドメイン駆動設計 1章メモ
今週から社内で読書会が開かれることになった。基本的には事前に読んでくるスタイルの会ということで第1回の範囲となる1章を読んだので、雑に取ったメモを放流。
1章 知識を噛み砕く
- ドメイン知識が無い状態でもの(PCB)を作った体験
- ドメインエキスパート(PCB回路設計者)がソフトウェアが達成すべきものをよく知っているわけではない
- ドメインエキスパートと話し合う中で語彙を研鑽する
- 用語の不一致を正す、使うべき言葉をドメインエキスパートが学ぶ
- 処理の流れ(モデル)を一緒に書いていくやり方が良い?
- 登場人物の名前を知る
- 登場人物の関係を知る
- 処理の名前を知る
- 処理の概要・目的を知る
- ドメインエキスパートとの議論においてソフトウェアの詳細に立ち入り過ぎないよう気をつけるべきっぽい
- "すみません、詳細に立ち入りすぎました"
- ドメインモデルを注意深く作成することで本質的な処理を見つけやすくなる?
- "その後ほんの数日のうちに〜実際に計算したことには変わりない"
- ドメインエキスパートと一緒に図を作ったことで、あるドメインの複雑さの中で今回つくる機能が持たねばならない部分がどこなのか、を開発者単体で考えたときと比べて精度高く知った状態で開発に入ることができるのでは
- 複雑さを見誤るとどんなに設計が良くても負債になりそう
- 例えば Web アプリだと DB の設計を含むくらい機能開発をするときにはミスると辛いしそこを境界線として特に注意深くドメインエキスパートとコミュニケーション取りながら作る、みたくすると良いのかもしれない
- ドメインエキスパートと一緒に図を作ることでソフトウェアの構造をドメインエキスパートより理解できるようになる
- ドメインエキスパートと一緒にモデルを作成しソフトウェアを開発することで、ドメイン知識がソフトウェアに組み込まれる
- 本ではドメインエキスパートがオブジェクト間の相互作用を提示するまでになってるけどそれを望むのはきつそう
- 顧客が本当に求めているものを協力して探すには、やはりモデルを一緒に作るのが良さそうに感じた
- "モデルを改良すると、コードも一緒に進化した。数カ月後、PCB 技術者は自分たちの期待を上回る、機能豊富なツールを手にしていた。"
効果的なモデリングの要素
- 筆者によるこの話についてこれが成功の秘訣だったリスト
- モデルと実装を結びつけること
- モデルに基づいて言語を洗練させること
- 最初辛い(主にドメインエキスパートが)けど相互にモデルを理解できるようにしておくことでモデルの構造と矛盾しない思考で議論することができるようになった
- 知識豊富なモデルを開発すること
- モデルは単なるデータスキーマではなく、複雑な問題を解決する振る舞いと守るべきルールがある。クゥ〜ッ
- モデルを蒸留すること
- 蒸留 = 本質的でない概念を切り捨てる
- ブレインストーミングと実験をすること
- モデルの形を色々と書いてみては議論することで使えるか調べた
- このときに会話がぎこちない = このモデルはダメそうという判断ができた
- (ravelll)開発者がドメインエキスパートのとき DDD を利用する利点はあるのか
- ユーザーを登場人物に含めて間接的にモデルについて議論する、と考えるとモデルを洗練させ実装と一致させる狙いで利用する意味が十分ありそう
- DDD が良いのは翻訳による情報の欠如や時間的なロス、人間関係の改善とするなら、ユーザーと直接話すことはなく開発者がただ議論するだけなら翻訳のオーバーヘッドも小さそうなので実は効果的ではない?
知識の噛み砕き
- "噛み砕く" = それの根底にある意味を知るプロセス
- "ドメインモデルを噛み砕く"ということ
- 情報の流れを掬ってその重要な意味の大部分を理解できる抽象的なモデルを見つけること
- 知識の噛み砕きは一人で行うものではなく、開発者とドメインエキスパートで行う
- 大抵は開発者が率いる
- 知識噛み砕きプロセスの失敗事例
- (1.) ウォーターフォールでの流れ
- ビジネスエキスパートがアナリストに話をする
- アナリストが情報を噛み砕き抽象化する
- ソフトウェアエンジニアがそれを実装する
- この流れにはフィードバックのタイミングがない
- アナリストが基にするのはビジネスエキスパートの話だけ
- (2.) イテレーティブにやってるけど抽象化してなくて知識が積み上がらない
- 何を作るかビジネスエキスパートに聞いて実装し、終わったら提示する
- "何を作るか" だけに集中するとモデルの蒸留が行われなくてダメそう
- "そうしたやり方でも(snip)既存機能の必然的な帰結として強力な新機能が現れるという段階には、決して到達することがない。"
- ゴールド・エクスペリエンス・レクイエム!!
- 抽象化もドメインエキスパートとの共同作業なしに行うとドメインエキスパートの考えと乖離してしまう
- "チームメンバ間のやりとりは、メンバ全員がモデルを一緒にかみ砕くことで変化する。" いい話っぽい
- ドメインモデルを絶えず改良すると開発者はビジネスにおける重要な原理を習得するよう強いられる、というのがちょっとわかってない
- (1.) ウォーターフォールでの流れ
- うまく知識をチームが噛み砕けるとモデルはビジネスの深い知識を反映したものになる
- "改善されるにつれて、モデルは、プロジェクトの中を流れ続ける情報を体系化するためのツールとなっていく。"
継続的学習
- 生産的なチームを知識を意識的に育てる
- 十分な知識が無いことを認識することはしばしば難しい
- 知識はメンバーの入れ替えやアウトソーシング等によって流出する
- "技術的な知識" って例えば gRPC について知る、みたいな話?
- 知識があると知識の噛み砕きをよりうまくできるようになる
- 例えば PCB の事例について学んだところ
- (エキスパートとの対話を通じて)アプリケーションに関連する重要な概念の理解
- 構築している内容がただしいかどうかのチェックを行うこと
- 大事なのは共同作業によって作成されたモデルが残ることではなく知識の噛み砕きのプロセスを起こさせること
- 知識の噛み砕きが行われることで以後の作業がより効果的になる
知識豊富な設計
- 設計やリファクタリングはモデルの変化を主軸として行われるもの
- 逆に言えば、開発者はモデルの変化に機敏に対応できる設計にし、実際に追従していかねばならない
- 存在しているエンティティやコードを超えて、相互作用やビジネスルールに注目する
- コードは合っているがビジネスルールとして矛盾している、ということに気づける
- この辺コードレビューしてるとどうやったら気付けるのかな〜とよくなる…
- 普段から背景となるビジネスルールまでを考えてコードを読み書きすることで一歩抽象度の高いレビューができるようになる?
- 人間は自身が触れている世界のプロセスを処理する中おきるギャップを思考によって無意識に調整・補完している
- そんなことはソフトウェアにできないので、知識をちゃんと噛み砕いて具体化させ、実装したり切り捨てたりする
- 貨物船の例
深いモデル
- アプリケーション作ってるときにそれを誰がどう使っているのかを勝手に思い込んでいらない機能を作る、というのは超あるあるという感じ
ISUCON9 予選に参加してきました #isucon
チーム泥酔チャンスとして同僚の @manicmaniac, @mpls104 と共に参加してきました。ISUCON 予選に参加するのは ISUCON7 ぶりで、ポジションは当時から変わってインフラ担当。
やったこと(〜前日)
- リハーサル環境の構築
- Alibaba Cloud の ECS に ISUCON7 の環境を作った
- chaspy/terraform-alibaba-isucon8 がウルトラ便利でした、感謝🙏
- デプロイスクリプトの準備
- 設定をまとめた nginx.conf, my.cnf の準備
- メルカリ社が出題担当なら nginx(OpenResty) + MySQL かな、そうに違いない!そうであってくれ頼む〜という心境でした(h2o や PostgreSQL に疎い)
- puma, nginx, MySQL の設定・インストールの素振り
- ログ解析の素振り
- kataribe, mysqldumpslow, pt-query-digest
やったこと(当日)
アプリケーションのコードはほとんど変更せずに終わってしまった。
- インスタンス作成
- コードを commit
- ミドルウェア周り色々
- 設定のバックアップ、ダンプ、設定変更、ログ解析など
- /users/transactions.json の改善
- /buy の自商品購入時に 403 を返す処理をトランザクション外で行う
- SELECT FOR UPDATE 回避の意図だったけどよく分からんしとりあえずやる〜?くらいの感じだった
写真は当日のホワイトボードの様子。書き殴られている。
結果
4010点でした。
このスコアには開始3時間くらいで到達した(ログを見ると12:47:47)のだけど、5時間そこから伸ばせず終わってしまった…
POST /buy
で 403 が増え続け、何が理由なの〜とみんなで数時間唸っていました。ちゃんと復習せねば。
反省
- とにかく準備に余裕がなかった
- 8月半ばまでメンバー募集してたり体調悪かったりスケジュールが詰まってたりした。余裕のあるスケジュール大事
- ドキュメント読みつつアプリケーションをじっくり触る時間を取ればよかった
- ISUCON7 のときも言った気がする…
- puma のログをちゃんと出しつつやればよかった
- 事前に素振りできてなくて、なあなあで出さないまま続けてしまった
- アプリケーションのコードを一通り眺めて怪しい要素をリストすれば良かった
- 終わってから "そういや bump って何?" となってダメだった
- ボトルネックとなっている処理の周辺しか眺めなかった
- 明確に役割分担をしておくべきだったかも
- A さんは X についての知見をためておき当日は手を動かしてもらうこと、というのを合意して学習を効率化すべきだったかも
- 一部調査が被った
- インフラの設定を複数人がカジュアルにいじって知らないうちに死んでた、ということが何度かあった
- A さんは X についての知見をためておき当日は手を動かしてもらうこと、というのを合意して学習を効率化すべきだったかも
今回は事前準備が全然できなくて "みんなで楽しめればそれで優勝" くらいの気持ちだったのだけど、いざ成果を出せずに終わるとやっぱり悔しい。前回はウオオオとなる瞬間が一度はあったのだけど、今回はそういった機会が本当に一度もなくヌル〜ッと終わってしまったのもやや悲しかった…とはいえ歯が立たなかったということはそれだけ学ぶべきことが多かったということなので、後日ちゃんと振り返りして糧にしたいですね。
そして次回があるならばもっと余裕を持って臨めるといいな。次回のメンバーを早速募集します。当方ピアノ兼 Ruby 。
builderscon 2019 に参加してきた
builderscon に参加するのは第1回の 2016 ぶりで、当時と比べてかなり規模が大きくなっていて驚いた。
カンファレンスは持病の問題でどうしても寝落ちしてしまう*1ので最近は参加を躊躇しがちで、今回もやはり一部のトークは寝落ちしてしまったのだけど、好奇心を刺激するトークの連続でとても楽しかった。
特にスーパーカミオカンデの話はほぼ終始馴染みのない話で、"知らなかった、を聞く" ことが最も強く満たされたトークだった。 スーパーカミオカンデの一般公開の抽選も応募するぞ。もしも当たると公開日の翌日 VimConf なのでスケジュールが大変なのだけど、それでも見てみたいなあ。
また DQNEO さんのコンパイラをライブコーディングで作っていくトークには痺れた。途中から会場全体でモブプログラミングをしているような状態になったのも楽しかった。
トークを聞いて僕もコンパイラ書くぞ!!!と熱が高まったので早速 DQNEO/HowToWriteACompiler を ruby で再実装する形で書いてみた。気が向いたときに少しずつ拡張していけるといいな。
またトーク以外でも元同僚や知人と何人か会って話せたり、なかなかお会いできる機会がなかった id:a-know さんとついにお話しできたりしてとても良かった。
高まった気持ちを維持して明日からもやっていくぞ。週末は ISUCON 予選もある。