1章メモ今週から社内で読書会が開かれることになった。基本的には事前に読んでくるスタイルの会ということで第1回の範囲となる1章を読んだので、雑に取ったメモを放流。設計を含むくらい機能開発をするときにはミスると辛いしそこを境界線として特に注意深くドメインエキスパートとコミュニケーション取りながら作る、みたくすると良いのかもしれないドメインエキスパートと一緒に図を作ることでソフトウェアの構造をドメインエキスパートより理解できるようになるその結果、ドメインエキスパートがソフトウェア開発に協力的になる、という流れがあるドメインエキスパートとの距離を感じたら大まかな設計を一緒にやってみることから始めると良いのかなソフトウェア開発者がドメインエキスパートとコミュニケーションを取るフレームワークとなった完全にいい話ドメインエキスパートと一緒にモデルを作成しソフトウェアを開発することで、ドメイン知識がソフトウェアに組み込まれる本ではドメインエキスパートがオブジェクト間の相互作用を提示するまでになってるけどそれを望むのはきつそう顧客が本当に求めているものを協力して探すには、やはりモデルを一緒に作るのが良さそうに感じた"モデルを改良すると、コードも一緒に進化した。技術者は自分たちの期待を上回る、機能豊富なツールを手にしていた。筆者によるこの話についてこれが成功の秘訣だったリストモデルと実装を結びつけることモデルに基づいて言語を洗練させること最初辛い(主にドメインエキスパートが)けど相互にモデルを理解できるようにしておくことでモデルの構造と矛盾しない思考で議論することができるようになった知識豊富なモデルを開発することモデルは単なるデータスキーマではなく、複雑な問題を解決する振る舞いと守るべきルールがある。集中するとモデルの蒸留が行われなくてダメそう"そうしたやり方でも(snip)既存機能の必然的な帰結として強力な新機能が現れるという段階には、決して到達することがない。"ゴールド・エクスペリエンス・レクイエム!!抽象化もドメインエキスパートとの共同作業なしに行うとドメインエキスパートの考えと乖離してしまう"チームメンバ間のやりとりは、メンバ全員がモデルを一緒にかみ砕くことで変化する。重要な原理を習得していないことはドメインエキスパートとコミュニケーションを取ってモデルを作ることを妨げるから?うまく知識をチームが噛み砕けるとモデルはビジネスの深い知識を反映したものになる"改善されるにつれて、モデルは、プロジェクトの中を流れ続ける情報を体系化するためのツールとなっていく。気がつけば転職してから半年が経とうとしている。#isuconはてなブログをはじめよう!ravelllさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。