【書評】Domain-Driven Transformation: Modernize Legacy Systems and Mitigate Risk
オライリーのサブスクで「Domain-Driven Transformation: Modernize Legacy Systems and Mitigate Risk」のAI自動翻訳版、「ドメイン駆動型トランスフォーマー変換」が出ていた。非常に勉強になったので本の概要の紹介と感想を共有する。
本書について
DDDを学んだ後、既存システムをどうリファクタリングしていくべきかで迷うリーダーに向いた本である。DDDの概念説明はあるが、入門というより「DDDの知識をどう使うか」を具体的に示す構成である。架空の会社の事例が章ごとに用意されており、学んだ知見を現場の意思決定に落とし込むイメージがつく。結論として、本書は「DDDの実務的な適用手順」を知りたい人のためのガイドと言える。
本書で解説されているドメイン駆動型変換は、概ね以下の流れで進める。
- 技術的、戦術的、チーム組織的なドメイン駆動型変換
- 技術的安定性
- ドメイン知識でソースコードを強化する
- 組織変更
- 戦略的ドメイン駆動型変換
- ドメインの再発見
- ドメイン指向の目標アーキテクチャモデル
- 目標アーキテクチャと実アーキテクチャの整合
- 変換施策と優先順位づけと実装
以下、それぞれの狙いと要点をまとめる。
技術的、戦術的、チーム組織的なドメイン駆動型変換
戦略的分解に進む前に、基盤となるコードとチームの状態を整える段階である。ここを曖昧にしたまま戦略的再設計に進むと、実行不能な理想論になりやすい。
技術的安定性
開発環境やテスト戦略を見直し、変換の土台を固める。
- ライブラリやインフラ最新化
- CI/CDパイプラインの整備
- テスト戦略
- メトリクスを用いた内部構造の改善
- nullに対する防御で堅牢性向上
- assertによる前提のコード化
ドメイン知識でソースコードを強化する
ドメインモデルを表現力豊かにし、コードが業務の意味を語る状態に近づける。
- リポジトリパターンでビジネスロジックからデータベースクエリを分離する
- getter/setterしかない貧弱なロジックにドメイン言語や値オブジェクトを導入
- Design by Contract
組織変更
- 単一のドメイン専門領域に集中し反復的アプローチを取る小規模チームを作る
- チームトポロジーの考え方でチームが自律して活動可能にする
戦略的ドメイン駆動型変換
戦略的/戦術的DDDを使って、コードとアーキテクチャをドメイン駆動型に変換していく段階である。ここからが本書の核となる。
ドメインの再発見
ソースコードではなくビジネスプロセスから真の境界づけられたコンテキストを発見する。
- ドメイン専門家を巻き込んで現状把握
- ビジネスプロセスからドメインを抽出
- 業務プロセスを最適化し、あるべきプロセスへ
- 目標業務プロセスにおけるサブドメインの発見
ドメイン指向の目標アーキテクチャモデル
前ステップでモデル化したサブドメインから、ターゲットとなるコンテキストマップを導出する。
- サブドメインと将来のビジネスプロセスからターゲットコンテキストマップを導出する
- コンテキストマップ内の境界づけられたコンテキストを中核、支援、汎用のサブドメインに分類する
- 個々の境界づけられたコンテキストにチームを割り当てる
- 境界づけられたコンテキスト間のインタフェースを定義する
目標アーキテクチャと実アーキテクチャの整合
レガシーシステムを目標構想に整合させる。
- アーキテクチャ文書(C4文書)やツール(Sonargraph)を使って実際のアーキテクチャの特定
- 目標コンテキストマップとソースコードの比較
- リファクタリングと発見事項の決定
変換施策と優先順位づけと実装
どのリファクタリングに最初に取り組むか明確にし、テスト駆動で実装を進める。
- 最初の戦略的リファクタリングの選択
- 戦術的リファクタリングをプロダクトバックログまたは改善バックログに追加する
- 達成可能なリファクタリングをスプリントバックログに計画する
- コンテキストの抽出（リファクタリングの実行）
まとめ
DDDを学んだ後に「では既存システムはどう変えていくべきか」と悩むリーダーにとって、本書は具体的な道筋を示してくれる。技術基盤・コード・組織・戦略を一貫した流れで扱うため、現場での意思決定の軸が得られる点が良い。入門書の次に読む一冊として、特にチームを率いる立場の人に向いている。
6歳版 | 宇宙を好きになって欲しい子供のための絵本・児童書6選
みなさん、宇宙は好きですか？
うちの子は、今も変わらず宇宙が大好きです。
最近は長い本も読めるようになり、まだ漢字は読めませんが、児童書にも挑戦しています。
この記事では、そんな子どもが特に気に入っている絵本と児童書を紹介します。
0歳〜5歳向けの絵本は以前の記事を見てください。
わくわく小惑星ずかん
いろんな小惑星を、かわいいキャラクターにして解説しています。
「漫画で紹介 → 小惑星の説明」という構成なので、まず漫画で興味を持てます。
図鑑が初めての子どもでも、最後まで読み進めやすい一冊です。
もしも月でくらしたら
月に移住したらどんな生活になる？と想像をかき立ててくれる本。
以前、図書館で借りたときは、そこまで興味がない感じでした。
しかし、竹中工務店の宇宙建築展に行ったあとにもう一度読んでみると、月面での生活をイメージできるようになったのか、食い入るように読んでいました。
www.takenaka.co.jp
ドラえもん科学ワールド 新版 宇宙の不思議
ドラえもんの宇宙に関する話をまとめた一冊です。
これだけで一冊になるほど話があり、「ドラえもんって、こんなに宇宙の話をしていたんだ」と感心しました。
漫画のあとに解説が続く構成で、解説はやや細かめです。
今は漫画だけ読んでいますが、いずれ解説にも手を伸ばしてくれたらと思っています。
JAXAxかいけつゾロリ 宇宙をめざせ！科学実験大図鑑
児童書界の人気者、かいけつゾロリが宇宙のあれこれを実験を通して解説してくれます。
いろんな工作の手順が紹介されているので、親子で一緒に挑戦すると楽しめます。
宇宙のお仕事図鑑
宇宙が身近になりつつある現代で、宇宙に関わるさまざまな仕事を紹介しています。
児童書ではありませんが、驚いたのは、すべての漢字に読み仮名が振ってあることです。
ひらがなとカタカナが読めれば、この本を一人で読めてしまいます。
本の最初のところに職業診断があるのですが、うちの子は「宇宙エンジニアだ！」「宇宙飛行士がいい！」と何度もやって楽しんでいます。
大人が読んでも面白いので、子供と一緒に「どんなお仕事したい？」と話しながら読むと良いと思います。
探査機はやぶささん
はやぶさを擬人化した四コマ漫画です。
プロジェクトの内容を、キャラクターを通してわかりやすく解説しています。
プロジェクトの裏話的な話も収録されているので解説本として普通に面白いです。
ふりがなは振られていませんが、絵柄がかわいく、子どもウケは抜群です。
うちの子も全部は読めませんが、一生懸命読もうとしています。
番外編
赤外線天文衛星あかりちゃん
商業誌ではないのですが子供がとても気にっているので紹介。
赤外線天文衛星あかりを擬人化して、プロジェクトの紆余曲折を解説した本です。
昔、研究室に冊子があったのを思い出して子供に読ませてみました。
ISASのホームページにPDF版があるのでPDFをカラー印刷して冊子にしました。
冊子にしておくにはもったいない完成度です。
ぜひ、子ども向けにふりがな付きで出版してほしいと思いました。
【書評】AIエージェント 人類と協働する機械
本を読んだきっかけ
今話題のAIエージェントを、どのように有効活用できるのかを学びたいと考えた。 また、著者の広木さんは、これまでの講演で過去の歴史を踏まえた分析や将来への提言を行っている。AIによる技術革新についても、歴史的な観点からの知見が得られるのではないかと思い、本書を手に取った。
著者／本に関する内容
著者は『エンジニアリング組織論』の著者である広木大地さん。 アーキテクチャやエンジニアリングをテーマに、さまざまなカンファレンスで講演している。
内容の要約
AIエージェントの登場によって、仕事はどのように変わるのか。本書は、次の問いに答えながら、これからどのように歩んでいくべきかを提案している。
- AIによって仕事は奪われるのか
- AIと協働する時代に、生産性をどう考えるべきか
- AIが普及した環境で、何を作ることが価値になるのか
新しく知った事例や気づき
過去の歴史やパターンから、今後どのように振る舞うべきかについて、一つの指針を得られた。 過去の技術革新では、仕事の二極化が起きている。高技能者の仕事は技術的に難しく、代替されにくい。低技能者の仕事も、経済的に代替するメリットが小さいため、置き換えられにくい。 一方で、中間技能者の仕事はルーティン化しやすく、経済的効果も大きいため、代替されやすい。そうした中で、優秀な中間技能者は新しい技術領域へとシフトしてきた。 そのため、継続的な学習や専門性の向上、あるいは人間的な価値を提供する能力の開発が重要だと理解した。
また、AIによって技術革新のスピードは加速しており、状況は目まぐるしく変化している。このような不確実性の高い状況では、未来を正確に予測するよりも、実験を重ねながら創造していく姿勢が重要だ。 本書で紹介されていたエフェクチュエーションは、不確実な状況下で、手持ちの手段（知識・人脈・資金など）から出発し、行動しながら未来を創造していく思考・行動のプロセスである。この考え方は、今後の仕事の進め方に取り入れていきたいと感じた。
もう一つの学びは、業務効率化を考えるうえで、アムダールの法則を踏まえ、並列化できない業務をどう改善するかが重要だという点である。 AIを導入すれば、コーディングは確実に速くなる。しかし、コーディングが速くなったからといって、開発全体が同じように速くなるとは限らない。 ある工程のボトルネックが解消されると、次のボトルネックは、並列化できない業務へと移動する。例えば、仕様策定やレビューのように、一貫性が求められる作業がそれにあたる。 自分の業務はまさにこの部分に該当するため、ボトルネックになりやすい工程こそ、AIをうまく活用すべきだと考えを改めた。
最後に、本書の中心テーマである知識創造システムの構築について。特に、SECIモデルを意識した知識循環を、AIを使ってどのように実現するかという点が印象に残った。 振り返ると、自社の取り組みは、SECIモデルの循環という観点が不足していたように思う。例えば、障害チケットを管理・分析して品質改善につなげる活動は存在している。しかし、分析のスパンが長く、分析する頃には開発が終盤に差し掛かっていることが多い。 その結果、SECIモデルでいう「内面化」まで十分に回っていない。途中まで循環できているにもかかわらず、素早く内面化できないため、活動の効果を実感しづらい状況になっている。 今後は、SECIモデルを意識し、知識循環のどこが不足しているのかを考えていきたい。また、AIを活用してSECIモデルを自動的に回す知識創造システムを構築できるようにしたい。
今年読んで良かった本まとめ 2025｜設計・ML・研究まで幅広く紹介
2025年も残り1ヶ月となりました。少し早いですが、今年読んで面白かった本をまとめます。 今年は技術書を多めに読み、仕事で強化学習を扱う機会もあったため、機械学習関連の本にも手を伸ばしました。
ソフトウェア開発
Tidy First? 個人で実践する経験主義的ソフトウェア設計
コードが読みにくく、1箇所を変えると他も直さないといけない――そんな現場のつらさを、「整頓」というワークフローで解決しようとする本です。
タイトルの “Tidy” は「整頓」と訳されています。整頓はリファクタリングの一部ですが、後者のように大がかりになりすぎず、自分の作業範囲で毎日続けられる改善手法として位置づけられています。本書は、この整頓を「いつ・どう・なぜ行うのか」を明快に示します。
私自身、リファクタリングは開発を止めてまとめて行うものだと思い込んでいました。日々の小さな改善として積み重ねる、という発想は新鮮で、紹介されるテクニックも扱いやすいと感じました。短い本なので、すぐ読めてすぐ実践できます。
パターン、Wiki、XP ―― 時を超えた創造の原則
自然界や人の営みには繰り返し現れる形があり、ソフトウェアで言えばデザインパターンがその例です。アーキテクチャがソフトウェアの方向性を決めますが、コンウェイの法則は組織構造がソフトウェアの構造と密接な関係があることを示します。そう考えると、「良いパターンとは何か」 という原点に立ち返ることが、良いソフトウェア設計や組織づくりにつながるのではないかと思い、本書を手に取りました。
本書は、建築家クリストファー・アレグザンダーがまとめた「パターン」「パターンランゲージ」、そしてそれがケント・ベックのXPやウォード・カニンガムのWikiにどう影響したかを解説しています。これらの思想の共通点を理解できたのは大きな収穫でした。
一方で、アレグザンダーにとってパターンは六つの原理の一つに過ぎないこともわかります。ソフトウェアではパターンに注目しすぎると視野が狭くなると感じ、むしろ彼の「良い設計とは何か」という広い原則に興味が向きました。建築とソフトウェアをつなぐ貴重な一冊です。
単体テストの考え方/使い方
今年の当たり本その1。多くの書籍がテスト手法を解説する中、本書は「良いテストとは何か」を深掘りしています。テスト観が大きく変わりました。
詳しくは以前のエントリーを参照してください。
センスの良いSQLを書く技術 達人エンジニアが実践している３５の原則
データベースの成り立ちを踏まえ、なぜそのSQLが良いのかを歴史と実例から解説する本です。
著者の「演繹的な考察は天才でなくてもできる」という姿勢が印象的で、MySQL・PostgreSQL・Oracleを比較しながら設計思想の違いがつかめました。実務での判断基準がはっきりします。
関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう
「単体テストの考え方/使い方」で純関数の扱いやすさを知り、関数型プログラミングを学びたくなって読みました。
関数型の基礎から、型でドメインを表現する方法、そしてDDDとの融合まで丁寧に説明されています。実務ではすべてを関数型にできないため、永続化など現実的な問題への向き合い方も具体的です。関数型を試してみたくなる一冊でした。
ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則
今年の当たり本その2。避けられない「結合」をどう扱うかに焦点を当てた本で、強度・距離・変動性という3つの軸で整理するアプローチが非常に明快です。
詳しくは以前のエントリーを参照してください。
機械学習
ゼロから作る Deep Learning ❹ 強化学習編
強化学習の基礎を急いで身につける必要があり、置いていかれにくい解説書を探して本書を選びました。タイトル通り、幅広い概念を数式とコードで手を動かしつつゼロから理解できる構成です。
詳しくは以前のエントリーを参照してください。
機械学習を解釈する技術 予測力と説明力を両立する実践テクニック
機械学習の解釈可能性、いわゆるXAIの入門書です。PFI・PD・ICE・SHAP などの代表的な手法を、数式は最小限に抑え、実装例と図でわかりやすく説明しています。
特に、複雑になりがちなSHAPを単純なケースに落とし込んで説明しており、「結局何をしている手法なのか」を理解する助けになります。
AIエージェント 人類と協働する機械
AIエージェントの登場によって、仕事はどのように変わるのか。本書は、「AIによって仕事は奪われるのか」「AIと協働する時代に、生産性をどう考えるべきか」「AIが普及した環境で、何を作ることが価値になるのか」といった問いに答えながら、これからどのように歩んでいくべきかを提案している。
詳しくは以前のエントリーを参照してください。
その他
バッタを倒すぜ アフリカで
前作『バッタを倒しにアフリカへ』で強烈な印象を残した著者が、前作では語れなかった研究内容を本書で存分に紹介しています。
サバクトビバッタの集団別居仮説を、フィールドワークと目視カウントというローテクで検証し切った執念に圧倒されました。研究への情熱が伝わってきて、読み物としても学術書としても面白い。研究者の熱意は読者のモチベーションをも上げてくれます。強くおすすめです。
みんなが読みたがる文章
「読まれる文章の書き方」をまとめた一冊です。 ここ数年、知識の定着のために本のまとめを書いていますが、どうせ書くならもっと読みやすくしたいと思い、Xで見かけた感想をきっかけに購入しました。
本書では「短く簡潔に書く」など12のテクニックを紹介しており、特にこの「短く、簡潔に」は繰り返し強調されています。今後の書評を書く際にも大いに役立ちそうです。
【書評】ソフトウェア設計の結合バランス 持続可能な成長を支えるモジュール化の原則
どんな本？
ソフトウェア設計では、モジュール間の結合をどれだけ適切に設計できるかが重要である。
本書は、この「ソフトウェアの結合設計」というテーマを深く掘り下げた一冊だ。
著者は『ドメイン駆動設計をはじめよう』の著者、Vlad Khononov氏。
前著では、ドメイン駆動設計の考え方を具体例とともに非常にわかりやすく解説している。
その書籍については、別の記事で感想をまとめている。
内容の要約
ソフトウェア設計では、結合をなるべく減らす「疎結合」が推奨される。では、結合は本当に悪なのだろうか。
本書は、結合を悪と断じない。要はバランスである。結合とはコンポーネント間の相互作用だ。システムは複数のコンポーネントの組み合わせで成り立つ。相互作用がなければシステムは動かない。だから重要なのは「結合をなくすこと」ではなく、「どの程度の結合に収めるか」という見極めだ。
では、何を物差しにバランスを取るのか。本書は三つの次元を示す。強度・距離・変動性である。結合の強度が高いものは近くに置き、低いものは遠くに置く。強度が高いのに距離が遠い関係はバランスが悪い。ただし、変動性が低いなら、必ずしも直ちに是正する必要はない。
この三つの次元に至るまでの道筋で、本書は抽象化の要点を解きほぐす。複雑性から出発し、モジュール設計、コナーセンス、結合の諸論点をたどって考察を深め、最終的に強度・距離・変動性へと収束させる。読後に残るのは、この三語のインデックスだ。その導出過程自体が、抽象化の良い手本になっている。
思考実験
本書で学んだ知識を、自分の身の回りのケースに当てはめ、思考実験として実践してみる。
プロジェクト背景
ある企業向けにWEBアプリケーションを開発している。その中の一部に、特に複雑な機能があり、これを2つのチームで分担して開発している。
全体の規模が大きいこと、また対象機能に専門的な知識が必要であることから、「専門知識が不要なチーム」と「専門知識が必要なチーム」に分けて機能を割り当てている。ここでは仮にそれぞれをAチーム、Bチームとする。
Aチーム
主にフロントエンドを担当。ユーザーに入力画面を提供し、バリデーションチェックを行ったのち、データを共有データベースのテーブルに登録する。
Bチーム
バックエンドを担当。Aチームがデータベースに書き込んだことをトリガーに、テーブルからデータを取得して複雑な処理を実行する。
問題
この2つのチームは、共有データベースを介してデータをやり取りしている。そのため、このデータベースに対する変更コストが非常に高くなっている。
たとえば、Aチーム側の都合でテーブル構造を変更しようとしても、Bチームの処理に影響が及んでしまう。これは、フロントエンド側が対象の複雑な機能とは直接関係がないにもかかわらず発生している問題である。
分析
ここでは、本書で紹介された「強度・距離・変動性」、そしてそれらを統合した「均衡度」の観点からこの状況を分析する。
強度
AチームとBチームは、テーブルを介して相互作用している。ロジックを共有していないため、これはモデル結合に該当する。
モデル結合は、結合強度の中ではそれほど強くはないが、コントラクト結合ほど弱くもない。
距離
2つの機能を別々のチームが担当しており、開発上の距離は遠い。
変動性
両チームが担当する機能は、システム全体の中でもコアサブドメインにあたる。そのため変動性は高い。
均衡度
本書で示された均衡度の式、
均衡度 = (強度 XOR 距離) OR NOT 変動性
に当てはめると、
均衡度 = (高 XOR 高) OR NOT 高 となる。
均衡度のバランスは悪く、見直しを検討する余地がある。
改善案
強度・距離・変動性の各観点から、改善策を考えてみる。
強度
現在、2チームはテーブルを介して結合しているが、Bチームが実際には参照していないカラムも含まれている。
つまり、不要な情報まで共有してしまっている。
Aチームが必要なデータだけを抽出して提供するAPIを作成し、Bチームがそれを利用するようにすれば、共有情報を最小限に絞れる。
これにより、モデル結合からコントラクト結合へと移行でき、結合強度を下げられる。
距離
AチームとBチームの役割分担を整理し、対象の複雑な機能に特化した新チームを設ける。
同じチーム内で開発を進められるようにすれば、距離を縮められる。
変動性
コアサブドメインである以上、変動性そのものを下げることは難しい。
しかし、変動性を引き上げている要因である「複雑性」を減らすことは可能である。
複雑性には、専門知識が不可欠な本質的複雑性と、連携情報の多さなどによって生じる偶有的複雑性がある。
共有モデルの利用機能やタイミングを整理し、インタフェースや機能を分割することで、偶有的複雑性を低下させられる。
振り返り
これは思考実験であるため、最終的にどのアプローチを採用するかはここでは論じない。
ただし、本書を読む前に私が考えていた改善策は、チームを統合するという「距離」に関するものだけであった。
本書を通じて、結合のバランスをとるための複数の次元から問題を考えられるようになり、追加の2つの改善策を導き出せた。
強度・距離・変動性という考え方は、ソフトウェア設計における結合バランスを考察するうえで非常に実践的なツールであると実感した。
最後に
本書を通して、ソフトウェア設計では「結合バランスの調整」がいかに重要かを学んだ。
そのバランスを構成する次元は、強度・距離・変動性の3つである。
この3次元の視点から設計を見直すことで、より均衡のとれたソフトウェア構造に近づける。
【書評】ゼロから作る Deep Learning ❹ 強化学習編
急ぎ教科学習の基礎を身につける必要があり入門書を探していた。他の強化学習本で置いてかれてしまって、わかりやすいと評判の本書を手に取った。まさにゼロから作る、というタイトルにふさわしい。強化学習について幅広く、数式も追いつつ、実装例も学ぶことができる。
- 抽象から具体の説明がとても丁寧。とくに具体の方は必ずシンプルな例で説明してくれる。
- 提示されているコードの説明が豊富、また必要なところを絞って説明した後にそれらを統合した全体像を見せてくれるので、必要なコードに集中できる。
- 今までの復習を何度も入れてくれるので、アレなんだっけ、っていうのが先回りして対策してあるため前のページを読み返すことなく読み進められる
【書評】人工衛星の“なぜ”を科学する
NECの衛星を中心に衛星開発の概要がまとめられている。軌道制御の話などは非常にわかりやすかった。2025年に改訂版が出て内容が新しくなっています。
