|
| 1 | +--- |
| 2 | +title: "書評: データモデリングでドメインを駆動する" |
| 3 | +date: 2024/11/07 00:00:00 |
| 4 | +postid: a |
| 5 | +tag: |
| 6 | + - 書評 |
| 7 | + - データモデリングでドメインを駆動する |
| 8 | + - アーキテクチャ |
| 9 | + - データモデル |
| 10 | +category: |
| 11 | + - Business |
| 12 | +thumbnail: /images/20241107a/thumbnail.jpg |
| 13 | +author: 真野隼記 |
| 14 | +lede: "杉本さんのデータモデリングでドメインを駆動するを取り上げます。" |
| 15 | +--- |
| 16 | +<img src="/images/20241107a/TH320_9784297140106.jpg" alt="" width="320" height="454" loading="lazy"> |
| 17 | + |
| 18 | +[秋のブログ週間](/articles/20241028a/) 5本目です。 |
| 19 | + |
| 20 | +# はじめに |
| 21 | + |
| 22 | +TIG真野です。秋のブログ週間のサブ企画である、アーキテクチャ設計に絞った書評連載の1本目です。 |
| 23 | + |
| 24 | +杉本さんの[データモデリングでドメインを駆動する](https://gihyo.jp/book/2024/978-4-297-14010-6) を取り上げます。基幹システム系のアーキテクトとしてデータ設計は抑えておくべき要素の1つかと思っています。 |
| 25 | + |
| 26 | +## どんな本か |
| 27 | + |
| 28 | +以下、個人意見です。宅配クリーニングや物販などいくつか具体例を上げて、業務のデータモデリング（≒帳**簿**設計）を重視した「いぶし銀」な書籍です。データモデルは各DB実装に依存しない、帳簿（※帳票とは異なる！）のような概念であると本書では定義しています。このデータモデルについてフォーカスを当てた、最近出版された本として貴重な存在かと思います。なお、サロゲートキー／ナチュラルキー、テーブル分割、論理削除、適用開始終了日などは論理DB設計とし、インデックスなどDBに閉じる部分は物理DB設計と定義していました。 |
| 29 | + |
| 30 | +論理／物理DB設計は設計、実装テクニックの話が多いと思います。この書籍でも12章で触れられていますが、テクニック自体を語るというよりは、これらの課題が「偶有的複雑性」として発生しているといったような、俯瞰的な考えを伝えることを重視していて、明日から開発で使える実践的な実装テクニックを学べる書籍ではないと思います。 |
| 31 | + |
| 32 | +今どきの本だなと思ったのは、CQRSなどの非同期処理が、データモデルにどのように影響を与えるかや、DDDのドメインモデルがデータモデリングとどのような関係にあるのか？という説明があった点です。表紙にもありますが、DDDの共感する部分と、批判的な部分の記載があります。バチバチというより、概ね穏当な内容かと思いました。 |
| 33 | + |
| 34 | +個人的には少し浮ついた、生成AI（LLM）がどう基幹系システムの進化に影響するかといった話を聞きたかったです。その意味でいぶし銀！な印象を持ちました。 |
| 35 | + |
| 36 | +## どんな本ではないか |
| 37 | + |
| 38 | +以下の話はほぼ無いです（前述の通り多少は触れている章あります） |
| 39 | + |
| 40 | +- より性能が良いテーブル設計や、SQLの書き方を含む、個別プロダクトの設計／実装の話 |
| 41 | +- DDD文脈でのドメインモデルの設計方法、実装方法 |
| 42 | +- 業界／業務ごとに良くある業務ロジックパターンの説明 |
| 43 | + |
| 44 | + |
| 45 | + |
| 46 | +## アーキテクトを目指す人におすすめの本なのか？ |
| 47 | + |
| 48 | +Yesです。ただ、中級者向けです。また、クラウドのサービスをどう取捨選択するかといった話は学べません。そして、過去の経験で一度も業務システムの開発に関わったことが無いと、イメージが湧きにくいかもと思いました。最初に背伸びして読むのは良い刺激となりますが、文章の内容がピンとこなくても自信を無くさない（また数年後読んで差分を楽しむ）という付き合い方かなと思います。 |
| 49 | + |
| 50 | +個人的には、この書籍は読者への問いかけを上手く投げかけてくれています。例えば以下のような具合です。 |
| 51 | + |
| 52 | +- 「大阪の得意先から受注した商品に関して、大阪では在庫切れ、東京には在庫があるとすれば、東京の在庫を回してよいものでしょうか。名古屋の得意先からの受注に対しては、東京・大阪いずれの倉庫から出荷すべきでしょうか」 |
| 53 | + - 受注数にもよるし、適正在庫の状況にもよるし～など、様々な考え方があることが分かる |
| 54 | + |
| 55 | +こういった問いかけを通して、業務システムの難しいところ、面白いところを学べるのはSIer／ITコンサルタントの立場の人には嬉しいと思いました。 |
| 56 | + |
| 57 | +過去、フューチャーの先輩が以下のように話していたことを思い出しました。 |
| 58 | + |
| 59 | +- 「モノを動かすと即時対応ができない、業務が非同期になる。これを上手くデザインすることが難しいし楽しい」 |
| 60 | + |
| 61 | +本書でも、「要求と充足の間にタイミングの差があるため、未処理残を把握するために帳簿が必要になる」とあり、その重要性が語られています。 |
| 62 | + |
| 63 | +業務システムのアーキテクトとして、上記のような想像を持てないことには、どこか業務的にクリティカルで重要かなど見極める勘所が分からなく、アプリ側の要件が固まってから検討を進めようとなりがちです。しかし、業務的な勘所がざっくりとでも分かると、この部分は業務上、変更が多く入りうるポイントであるため、採用技術としては枯れたものを利用しようとか、品質保証をしやすい構成を取るようにしようと行った先手が思いつくと思います。 |
| 64 | + |
| 65 | +## アーキテクトとしてプラスになる部分 |
| 66 | + |
| 67 | +ビジネス設計に寄り添う／踏み込む重要性を改めて学べる、という点は確実に言えます。書籍にもありましたが、「在庫の引き当てより、計算式の解釈／実行やメモリ上のキャッシュ管理アルゴリズムのほうが興味深く感じられる」ものです。放っておくとどうしても実装テクニックよりのところに関心が向きがちなので、定期的にデトックスするためにも本書の存在は有益です。 |
| 68 | + |
| 69 | +データモデル（帳簿設計）はアプリケーションの領域でしょうか？という問いも考えられますがどうでしょうか？ アーキテクチャはビジネスの射影でもあるよねという立場からすると、アーキテクト的なポジションの人も要件インプットとして知っておく必要があると私は思います。 |
| 70 | + |
| 71 | +例えば、マイクロサービスをどのようなサービスカットで作成するかといった設計は、DDDでいう「境界づけられたコンテキスト」で考えてみることも多いと思いますが、その単位がどのような「帳簿」「残（※詳細は書籍に！）」があるかという観点で、整理できると有益な場面も多そうだと感じました。 |
| 72 | + |
| 73 | +## ユーザーとエンジニア双方にとって健全なアーキテクチャ設計 |
| 74 | + |
| 75 | +「可変性」という話がいくつか出てきます。例えば、先ほどの受注における出荷指図のロジックで、業務要件がフワフワしているとします。嫌ですね。早く決めたい／決めて欲しい。本書ではこうしたビジネスロジックが、ユーザーにとって1番の関心事がなんだ、と表現しています。開発者的には困ったな～、要件を決めてよ～って話ですが、ユーザーからすると、ここを柔軟に対応できることが、企業競争力や業務効率に直結するのでこだわりたいポイントです。これは「モノ」を動かす以上、人、お金が動くので当然です。 |
| 76 | + |
| 77 | +また、要件が変化しやすいポイントは、業務ユーザーとエンジニアの間で緊張が生じやすい。例えば挙動を変更するとエンジニアに依頼するので上下関係が生まれやすい。一方で一旦開発に入れば、リードタイムなどはエンジニアの手に委ねられ信頼するしか無いといったくだりがあります。確かに経験上、これはヘルシーな状況でないです。プロダクトオーナーと開発チームの信頼関係を構築するテクニックは数多ありますが、そもそもそれらが必要となる状況を減らせたら？ |
| 78 | + |
| 79 | +その対策の例として、「テーブル駆動方式」といった形式で柔軟性をもたせたり、DSLでユーザーが拡張可能にする話があります。興味深いですね。DSLあたりはアーキテクトレベルの人も関心が強いのではないでしょうか？ DSLは適度な制約が無いとシャドーITのごとく統制が取れなくなりますし、とはいえルールが強すぎても使い勝手が悪くなり使用されないと本末転倒です。 |
| 80 | + |
| 81 | +ローコードツールなども、ユーザーが自由に操れる「可変性」という領域に組み込まれるとより、よりユーザビリティが高められそうだなと私は感じます。いい感じに制約を付けられてかつ、組み込み型のローコードぽいツールを使ってみたい。 |
| 82 | + |
| 83 | +## 章ごとの雑感 |
| 84 | + |
| 85 | +いくつか特徴的だと思った章をピックアップして、面白いと感じたポイントを記載します。 |
| 86 | + |
| 87 | +1章 基幹システムとデータモデリング: |
| 88 | + |
| 89 | +- 「データモデリングとは、帳簿をデザインすること」 |
| 90 | + - 単なる事実の記録でもなく、帳票やテーブル定義でもなく、帳簿とは何か？が分かると、これをユーザーと対話してモデリングしないとならないことがよく分かります |
| 91 | +- 帳簿設計≒データモデリングだとすると、システム開発プロジェクトでは基本設計フェーズより前に行う必要があると思います。おそらく要件定義。業務一覧／業務フローを定義しつつデータモデルを精緻化していくと想定 |
| 92 | + |
| 93 | +4章 活動のシステム（SoA）残概念に基づく業務・帳簿の分割: |
| 94 | + |
| 95 | +- 「残」という概念に基づく、業務整理はかなり興味深いです！ |
| 96 | + - 「残」を通して、ビジネスが駆動し、責任分担を明らかにするということ、納得感があります |
| 97 | +- マスタ（リソース）について、データモデリングとの位置付けについて説明があります |
| 98 | + - 個人的には、「業務領域別チーム」とは別に結成された「マスタ管理チーム」についての話があり、興味深い見解だと思いました |
| 99 | + |
| 100 | +5章 経営管理のシステム（SoM）: |
| 101 | + |
| 102 | +- 経営管理領域でデータ管理粒度は「小は大を兼ねない」、という話は納得感が凄かったです |
| 103 | + - 分からなければとりあえず細かい粒度で持っておこう、と個人的にはなりがちですが、そうすると使えないシステムになりかねないということが分かり、真正面から考えていかないとならないと思いました |
| 104 | + |
| 105 | +9章 マスターの共有─ エンティティとロール方式 |
| 106 | + |
| 107 | +- 「支払システム」と「人事システム」の2つがあり、支払いシステムの都合で「振込先口座」を複数にしたいという要望が、人事システムが持つ「従業員マスタ」に追加する是非について話があります |
| 108 | + - 数少ない「あるよなー」と思った章です。マスタデータ管理はこのDX／生成AI時代にも重要度が増していて、どうすればよいか悩みが深いです。書籍上はわかりやすい解こそないものの、示唆に富むアドバイスが書かれています |
| 109 | + |
| 110 | +12章 偶有的複雑性に対処する──論理削除，テーブル分割，時系列データほか: |
| 111 | + |
| 112 | +- 珍しくテクニカルな設計論チックなことを説明する章です |
| 113 | + - 本書では本質的に難しい点と、偶有的複雑性の点は分離しようという点で説明しており、新しい観点を得られると思います |
| 114 | + |
| 115 | +もっと沢山、気になるポイントがあるのですが、「なるほど～」「たしかにな～」という感想を超える付加価値コメントができずで省略しています。このほかにも著者の豊富な経験と深い思考によって生み出された、示唆に富む内容がたくさんありました！ |
| 116 | + |
| 117 | +## さいごに |
| 118 | + |
| 119 | +「あ～、こういうパターンあるよね！」といった共感＋紹介／解説する書籍では全く無いなと思います（共感した内容もありますが）。杉本さんの思想（SoA、SoMの区別など）などもあり、あるべき姿が前提として説明されているため、どちらかといえば薫陶をもらえる系のヘビーな本だと思います。この記事を書くために3回読み返しました。 |
| 120 | + |
| 121 | +その分、濃密で示唆に富んでおり、この先、業務で「モデリング」する際には大きな助けになるなと感じます。人によって響いたポイントは異なると思います。みなさんの書評もお待ちしています！ |
| 122 | + |
0 commit comments