杉本啓さんの本の背景
株式会社株式スタイルの後藤英典です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、杉本啓さんの本、「データモデリングでドメインを駆動する」を読んでみた、です。
この本、今結構話題になってますよね。
私自身、この本を読んで、ものすごくいっぱいお話ししたいことが湧いてきている状態ですので、
今日はそれらについてお話ししてみたいと思っています。
エンジニアリングマネージャーの問題集。
本日は、マネージメント方面ではなくて、よりエンジニアリング方面っていうんですかね、
ある本について語りたいと思っています。
取り上げる本は最近出版された、「データモデリングでドメインを駆動する」という杉本啓さんが書かれた本を取り上げます。
この本についていろいろ語りたいことがあるんですけれども、
本の内容自体ではなくて、若干関連情報みたいなところから入りたいなと思っておるんですが、
この本を書かれた杉本啓さんと、私でいうとちょっとしたご縁があるというんですかね。
この程度の表現は難しいんですけれども、いろいろ学ばせていただいたというところで、
私の過去のポッドキャストで何度か多分触れたことがあると思うんですけれども、
関西IT勉強宴会という勉強会がありまして、この勉強会自体は杉本さんではなくて別の佐野さんという方が主催されている勉強会でして、
かなり長く今でも継続されている勉強会ですと。
ふとしたときに、これ私がもういくつぐらいのときかもう忘れちゃったんですけれども、この勉強会紹介いただいて参加することになって、
そこに主催者の佐野さんと、この本の著者の杉本さん、それから後からまた名前を出しますが渡辺幸三さんですとか、
その他結構私よりも上の世代で、かつかなりいろいろな業務システムを作ってこられたり、
それからシステムを作るだけではなくて、そのシステムを作る方法論だとかいうところまで結構議論されて、
自分たちで構築されたような方々が集まっているとても幸運な勉強会というのがあって、ここに出会うというとても幸運を得たんですね、私は。
当時私はドメイン駆動設計というのをかなりハマってやっておりまして、私自身どっちかというとオブジェクト志向育ちなところがあるので、
ドメイン駆動設計素晴らしいみたいな感じで、この勉強会に乗り込んでいったらボコボコにされたといいますか、そんなもんでシステムが作れるのかというような感じで、
いろいろな議論をして学ばせていただいたというような、何ですかね、そういったほろ苦いというか甘い経験があったというところが、
僕と杉本さんの縁で、その後何度か、例えばツイッター上でちょっとやり取りさせていただいたり、たまに飲み会でご一緒させていただいたりとか、そういったところだったりしますというところです。
そこ自体はそんなところなんですけれども、少し本の内容に近づいて触れていくと、まだ本の内容その自体に入らないんですが、
まずこの本の中、本を読んでですね、結構しっかり読んだんですが、まず僕が最初に強調したいなと思ったのが、まだ内容じゃないんですよ。
この本の中で杉本さんが、杉本さんご自身の考えというのを聖地に書かれているんですけれども、その考えを構成する材料として、
こういった技術書ではよくあると思うんですけれども、他の方の業績というか、まとめられた考え方だったりっていうところを参照している部分が出てくるんですけれども、
そこにですね、何名かの日本人のエンジニアの方々っていうんですかね、の業績というのが登場していきます。
で、これって結構僕、最近のこういったエンジニアリング系の本の中では珍しいことなのかなというふうにも思っております。
皆さんどうですかね、こういう日本人のエンジニアの業績的なものを参照した本っていうのって、そんなに見かけなくなってるんじゃないのかなと思うんですよね。
日本の偉大なエンジニア達
具体的にどういう方々が参照されているかっていうと、まず椿正明さんという方が出てきて、この方はデータ中心アプローチというのを打ち立てられて、
広く活動された方で、皆さんの中にもデータベース、データモデルっていうのかな、作るときにリソースとイベントで整理しましょうみたいな話を聞いたことあると思いますが、
この辺りは椿さんの手法が起点になってるような話かなというところです。
で、それから椿さんと非常に近い位置にいる方で、また別の方も参照されていて、佐藤正美さんという方の話も出てきます。
この方は椿さんのデータ中心アプローチに非常に近いんですけれども、より理論的に精緻に構築されてる方ですね。
手法の名前で言うとTGKERモデルとか、それを改称してTMっていうふうに呼ばれてるんですけれども、それによってそのモデル自体の論理的な整合性が100%であるというようなことを打ち立てるために、
どのような規則が必要なのかとか、ものすごく精緻にやられてる方で、僕も佐藤正美さんのアカホンとかを持ってるんですけれども、
幅広くいろいろな哲学とか論理学とか数学とかを参照されながら、ご自身の理論を作ってこられてる方で、杉本さんの本からの参照で言えば、
佐藤正美さんの方で提示された経営課程と管理課程、事業課程みたいな分類があるんですけれども、このようなところから管理課程に着目しようみたいなアイディアとかを取ってこられてる感じですね。
偉大な方です。それからもう一人、先ほども名前を挙げた渡辺光三さんですね。渡辺光三さんでいうと、業務分析の中で3要素分析法というような手法を提示されて、
データとUIと業務手順みたいなところで業務を分析しようだったり、そういった分析をするためのツールをご自身で作って、
それでやっていこうみたいなことまでされてる方なので、本当にそういった手法の提案だけでなく、それをするためのソフトウェアまでご自身で作って、
かつ、それでシステムを作っちゃうという、全部事務でやってるというところが、本当にマルチにやられてるすごい方だと思いますし、
データモデリングに関しても渡辺さんがライブで業務をヒアリングしながらデータモデリングするみたいなことも結構取り組みとしてやられていて、非常にエキサイティングだったりするんですよね。
聞いてらっしゃる皆さんの中にもそういったところを見たことがある方もいらっしゃるんじゃないかなと思っていて、
これ以外の方も名前が出てくるんですけれども、こういった日本の中でもすごい活動と業績っていうんですかね、
単にシステムを作ったというだけではなくて、システム作りに関する理論、体系みたいなところを打ち立てられた、
そういった業績っていうものを参照しながら、杉本さん自身のある種理論だったりフレームワークだったり知識体系っていうのを作っている、その内容がこの本に書かれてるっていうことなんですよ。
繰り返しになりますけれども、こういった日本の過去の偉大な業績というか、かつそういう人たちっていう、
こういう人たちがいるっていうことに、僕としてはスポットを当てたいなと思うところがあって、
聞いてらっしゃる方の中で、知ってる方もいると思いますが、全然そんな方々が聞いたことなかったっていう方もいるんじゃないのかなと思うんですよね。
でも実はわりと身近なところに、すごくそういったモデリングだったりだとかシステム作りに対する考え方を精緻にやってこられたっていうところが存在してたりするので、
これは同じ日本人としてすごくもったいないことだなと思ったりするので、ぜひ杉本さんの本からそういった方々を知って、
そういった方々のどんなことをやられたのかみたいなところまで知るきっかけにもなるといいんじゃないのかなみたいなことも思ったりしました。
ちょっと脱線気味な話ですが、最初にスポットを当てたいのがここだったので、まず最初にお話ししました。
本の内容とアイディア
次に、まだ本の内容に行かないんですけれども、どちらかというと僕の過去の経験がこの本によって繋がったみたいなところがあって、
杉本さんの本、データモデリングっていうものを中心に書かれてる本なんですけれども、そこに何というのかな、結構、
今まで僕が見たことなかったようなまとめ方というんですかね。そんなような形になっていると。
そのまとめる際に、私が過去に学んできたような要素っていうのが入っていて、
それが面白い杉本さんのまとめ方というか、面白いだけではないというか、確かにそうだよなと納得できるようなまとめ方でまとめ上げられているというのがあって、
例えばどんな要素かというと、当然データモデリングだとか業務分析みたいなのが根底にあるんですけれども、
そこに対して、例えば僕自身はもちろんスタート地点、先ほど言ったようにデータモデリングではなくてオブジェクト思考とかドメイン駆動設計から入った人間で、
僕はそこからモデルって何ぞやみたいな旅に出たことがあって、哲学だとか認知科学とかそういったことを結構深掘りしていったんですよね。
で、ビトゲンシュタインの本を読んだりだとか、フランシスコ・バレラの本を読んだりだとか、いろいろしてたんですよ。
で、こういった要素がデータモデリングでドメインを駆動する本にも出てくるというところがあって、
フランシスコ・バレラの身体の延長としての道具みたいな話だとか、あとは哲学者みたいな話もいくつか出てくるというところで、
自分が学んだようなもの、要素としてこの本の中で再びつなぎ合わされてるっていう話もありますし、
あとそうですね、ドメイン駆動設計、僕が学んでた延長でアーキテクチャーとかモデルとかいろいろやってたときに、
MVC モデル、皆さんソフトウェアエンジニアなら聞いたことがあるMVC モデルを発案したトリグベ・リーン・スカークという方がいるんですが、
その方がMVC の後継のアーキテクチャーというか進化したアーキテクチャーとして、
DCI データコンテキストインタラクションというものを提示されてるんですよね。
この DCI っていうのはあんまり一般的にはなってなくて、ソフトウェア開発の中で普及してるアーキテクチャーではないんですけれども、
考え方としては、より我々が業務だとか、現実世界を見ている見方に、
より自然にフィットするようなアーキテクチャーなのかなっていうようなところなんで、
興味ある方は論文とか読んでもらった方がいいと思うんですが、
この DCI の要素とかも、実はこのデータモデリングでドメインを駆動するのの中に出てきたりするんですよね。
なのでそういった自分が学んできた要素、いろいろな要素が本を読み進めていくにつれ、
度々登場するので、なるほど、あの考え方がこういうふうに取り込まれてるんだっていうふうに驚きを感じながら読み進むことができて、
その辺りもすごく面白かったし、杉本さんすごいな、こういうまとめ方をするんだっていうふうに感じながら読んだっていうところがありますね。
そんな本の内容そのものではないところをあれこれ話してきましたが、話し出すときりがないんですけれども、
そろそろ本の内容について、これもぜひ本読んでほしいというのがそのままなんですが、
いくつか僕がピックアップすべきかなと思った点を話しておきます。
まず一つ目におそらく言わなければならないのは、この本データモデリングに関して書かれている本なんですけれども、
正直に言うと僕自身がデータモデリングっていうものをちゃんとわかってなかったなというところがありまして、
なんというかおそらく僕の中ではどこまで行ってもデータモデリングとデータベース設計というものを切り離せていなかったんだろうなというところに改めて気づいたところがあります。
このデータモデリングでドメインを駆動するという本の中でのデータモデリングっていうのは、いくつかの形で定義されているんですけれども、
最もわかりやすい特徴的なところであげると、データモデリングっていうのはユーザーのメンタルモデルだっていうふうに書かれているんですね。
もしくは別の言い方では帳簿のデザインですというふうに書かれていて、
これメンタルモデルって何かっていう定義も必要かと思うんですが、
少なくともユーザーサイドのものであるということはかなり明確に強調して何度も触れられているので、
つまりどういうことかというとユーザーサイドのものであるならばシステムの内部の話ですね。
プログラマーしか知らなくていいような内容っていうのはデータモデルに含まれてはいけないということなんですよ。
システムを作るときにこういうふうだったらいいのになとか、
実装者観点での工夫だとか、実装のために必要な共通化だったり情報だったりっていうところはデータモデルには入ってちゃいけないんですよ。
そうではなくてユーザーが情報をどういうふうに捉えているのか。
これもありのままの情報ではなくて少し抽象化したっていうんですかね。
データモデリングの基礎理解
ちょっとこの程度問題はぜひこの本を読んで感じ取っていただきたいんですが、
ユーザーが目の前に見えている電表そのものっていうことでもないんだが、ユーザーが抽象的に情報をどう捉えているのか。
業務をするときに頭の中にある情報の構造としてはこうだよねっていうものをモデリングする。
これがデータモデリングだと定義しているんですよね。
だから一番ユーザーに近い位置にあるんですよ。
ここが私の中ではちょっと弱かったところなんですよね。
そういう理解自体はあったんだけれども、実際システムを作るときに、
そういうユーザーの真正面にあるものとしてデータをモデリングしてはいなかったんですよ。
最初にお話ししたような関西IT勉強宴会だとか、
月本さんや渡辺さんの話とかを聞いていたにもかかわらずその理解はなかったというところは結構お恥ずかしい告白にはなるんですけれども、
ここは改めてこの本を読んで、そういった自分自身の理解だけではなくて、
自分自身のこういったデータモデルを道具として使うレベルの理解というところにはまったく至ってなかったなというところがありますので。
ここもそれによってデータベース設計とデータモデルはどう違うんだとか、
その違いによって当然データモデルっていうところでは何を表現して、データベース設計では何を表現できるのかとかいう話とかもこの本の中で触れられているので、
ぜひ読んでみていただきたいなというところです。
これがまず一つ目ですね。
で、二つ目に触れたいのが、おそらくこの本に書かれていることで、
一番ではないかもしれないが、かなり面白い新しいものだし、
ちょっと下賤な言い方をするとキャッチーな内容かもしれない、受けやすい内容かもしれないと思っているのが、
残という概念、残るっていう漢字を書いて、残と読むはずなんですが、
この残というものに着目して業務を分析したりだとか、帳簿を設計したりしようという話が結構この本の前半部分のまず大きな山場として登場するんですよね。
で、残を管理しようとか、残を中心に業務があるよねって別に言われてみたら当たり前のことだし、びっくりすることではないと思うんですけれども、
よくよく少なくとも僕自身がどういうふうにシステムを設計したり、データベースのテーブルを設計したりしてきたかっていうと、
必ずしも残というものには着目していなくて、そうではなくて、何ていうのかな、その残に取り込まれる情報というのかな。
例えば例で言ったほうが分かりやすいと思うんですが、注文の残とかがあるわけですよね。
何らかのECの業務をしていて、お客さんから注文が入ってきましたというときに注文の情報があって、
受注管理担当みたいな人が10件とか100件とか入っている注文の一覧みたいなものがあって、その一覧を受注残とか呼ぼうということなんですが、
その残りを処理していく、残りをゼロにするというか、それがその人の受注管理担当の責任という感じだったりするわけですよ。
このときに私自身の経験で言うと、この残という受注残みたいなものをメインに据えて、
業務だったりデータモデルを分析するというよりは、そこに入ってくる注文情報ですね。
その一件一件の注文情報がどういったものなのかというところに着目して、
システムを設計したりデータベースのテーブルを設計したりしていて、
残の方っていうのはそれの集まりですよねっていう脇役的な見方をしてたと思うんですよ。
でもそういった見方だと、この本を読むとそこからどうなるのかっていうことが書いてあるので、
あまりネタバレになるようなことは話したくないんですけれども、
そういった分析が業務もしくはシステムの密結合を生んでいるというような話になっており、
そうではなく、この残というものに着目して業務自体を見る、もしくはシステムを設計する、
情報をデザインするということをしたときに、もちろんひとひねりはあるんですが、
より密結合ではなく素結合な形の業務、もしくはシステムの設計につながっていくというようなエッセンスになっています。
ここは本当に僕自身も、ものすごく当たり前のようなことが書かれているにもかかわらず、
とても不思議に感じたので、何度も何度もこの残という概念が登場する4章あたりですかね、
そこから自分の考えというのを、あれこれ、ああでもない、こうでもないというのを書き出したりしながら、
理解を試みたというか深めたところだったりします。
今時点の僕の理解というか、この残という概念に関して何が起こるのかというと、
現実の人間が、例えばシステムというものが全く存在しない、紙だけで業務をしている世界みたいなのを想像すると、
注文を受けて、注文の一覧があります。そこに受注残があります。
それとは別に注文されたもの、1個の商品しか扱っていないと仮にしたとしても、
1個の商品が在庫として、どこかに倉庫の中にあって、在庫の一覧みたいなのがあって、
在庫の一覧から出荷しますみたいなことをするとしましょうと。
注文の一覧に対して新しい注文が入った、だから受注残に変化があったということと、
受注に紐づいて在庫を確保して、それが出荷されて在庫が1個減るみたいなところって、
現実の世界で紙だけで管理するとしたら、分けざるを得ないんですよね。
受注の管理っていうノートみたいなのがあって、そこに受注の一覧を記録しておいて、
そこで受注を出荷しますみたいに消し込んだとしても、それとは別のページかもしれないけど、
書いてある在庫の一覧っていうところは、人間1人がやると仮定しても、受注のところをまず消して、
1秒後か分かんないけど、別のタイミングで在庫の方を消すとかやるじゃないですか。
完全に同時ってことはないし、一体化された1つの情報として、
全く同じタイミングで注文を消すっていう処理と在庫を消すっていう処理はできないというか、
必ずこれって別のタイミングで非同期に行われることになると思うんですよ。
で、この非同期に、現実の世界で紙とノートで業務していることを想像したときに非同期になるっていうのが、
割と人間の活動の本質というか、受注というものを管理せねばならぬ、
一方で在庫も管理せねばならぬ、この2つのものを管理している時の人間の活動っていうのが、
本質的に非同期になるっていうことなのかなっていうふうに思っていて、
だからそこは非同期にやるほうが、本質っていうのはちょっと違うかもしれないんですが、
自然になるというか、いうことだと思うんですよね。
で、なぜか我々はいろいろなシステム開発の道具の発展だとか、
RDBが性能が良くなったとか、いろいろな過程でこれらをシステムの中では一体化して扱うように、
同期的に注文が入ったら出荷の方も処理するというか、
いうふうに作りがちになってしまっているところがあると思うんですけれども、
本来は非同期に、疎結合に作ることができる業務だし、
人間の現実の活動を見たら、そもそも非同期でやってたよねっていうところで、
そこに立ち返った時に、受注の残っていうのと在庫の残っていうものに対して、
この本の中では、残の出入りっていう情報をそれぞれ別個に管理して、
非同期に作ることができるよねっていうような提案があるんですよね。
提案というか、多分杉本さんオリジナルの話ではなくて、
もともと帳簿で管理している業務ってそういうことだったよねっていうところに立ち返っているだけだと思うんですよ。
これは改めて見直すべき観点だなと思っていて、
そういった残を中心に物事を見ることで、
業務における非同期な情報管理
人間が複数のものを管理せねばならぬ時の自然な管理の仕方っていうところに立ち返ることができるし、
システム自体もその自然な切れ目に対して、
何らかの疎結合な非同期な仕掛けというのを入れやすい分け目になるわけですよね。
このポッドキャストの中で過去に何度かテーマに取り上げた、
システムを分けるのが難しいみたいな問題があって、
これって今話したような残を着目した時の業務の分かれ目みたいなところが
明確に見えないものに対してどう分けたらいいんだっていうのが難しいっていう話だったんだけれども、
それに対する一つの明確な答えっていうのが、
この本では示されていることになると思うんですよ。
これはすごく面白いことだし、
必ずしも全てのソフトウェアにこの話が適用できるわけではないんですけれども、
機関業務みたいな責任として着実に遂行しなければならない、
かつ残みたいなものの管理っていうのがあって、
それが別々に行われるっていうようなタイプの業務のシステムであれば、
この考え方っていうのは結構普遍的に適用できそうだなというところがあって、
非常に面白いなと思って読んでおりましたので、
ぜひこの残概念っていうところはこの本の中で、
まず最初の山ですし、
最も面白いところだと思うので、
ここだけでもしっかり読んで皆さん腹落ちしていただけると、
すごく得るものがあるんじゃないかなと思っているところです。
はい、ちょっと残のところの話が長くなっちゃいましたが、
もう一つ取り上げるとしたら、
エンティティとロールによるシステム設計の考え方
最後の方でドミンクロ設計よりも前ぐらいのところかな、
いろいろシステムを素結合にするためのデータモデリング観点での
個々の手法みたいなものが紹介されてるんですが、
その中でエンティティとロールっていう話が出てくるんですよ。
ここもすごく面白いなと思ったのは、
今回前の方で触れた中でDCIっていう考え方を紹介したと思うんですが、
その考え方が適用されてる手法のところなんですよね。
そもそもDCIって割とオブジェクト思考よりの文脈で
鳥上凛子さんは書かれてたかなと思うんですが、
杉本さんはその考え方をデータモデリングの世界の方に持ち込んで、
しかもすごくしっくりくるようなまとめ方で手法として紹介されていて、
僕自身はなるほどなとすごく腹落ちしたところだったりしたので、
少し触れたいと思います。
エンティティっていう言葉って、
ドメイン駆動設計の中でのモデリングの要素の一つとして登場したりするので、
言葉自体はよく聞いたことが皆さんもあるんじゃないかなと思いますが、
現実世界のものというか情報とかで、
さつ、一位に名指して識別できるものっていうような定義で、
具体的には例えば従業員っていう情報とか、
取引先っていう情報とかっていうのがだいたい従業員IDで管理されていて識別されたり、
取引先IDで管理されて識別されたりするようなもの。
そういった情報をエンティティって呼んで扱いましょうっていうようなことですよね。
これってドメイン駆動設計とかオブジェクト思考の世界だけじゃなくって、
データモデリングの話とかでももともとこの概念自体は出てきてるんですよ。
広く普及してる考え方です。
ただですね、ドメイン駆動設計なんかだと割といろんなところでエンティティというのが出てきてですね、
何でもかんでもエンティティになっちゃうというところがあって、
例えばさっきの例で言うと従業員をエンティティと呼びますというようなことがあったときに、
ちょっとシステムの話とは若干違うんですけれど、
プログラマーたちが集まった、エンジニアたちが集まったチームの中の、
そうですね、エンジニアリングマネージャーがいて、スクラムマスターがいてとか、
そういうチームの中を想像したときに、
エンジニアリングマネージャーも従業員エンティティなんですよね、その見方で言うと。
だし、スクラムマスターも従業員エンティティだし、
チームの中の役割っていうのを定義するようなときにも、
従業員エンティティのすべての情報は使わないけれども、
従業員エンティティとほぼ同じ、たぶん従業員IDか何かで識別しつつ、
この人がエンジニアリングマネージャーですとか、
そういう定義をして、そういうチームっていうものの情報を扱うと思うんですよ。
ただこのときに、たぶん個々の情報って従業員とはちょっと違う情報として扱うし、
チーム情報みたいなのを扱いたいときって、
もともとの従業員管理みたいなものとはコンテキストが違うんですよね。
ドメイン駆動設計だとバウンデッドコンテキストみたいな概念で、
違うコンテキストではちょっと違った情報を扱いましょうみたいな話が出てくるんですが、
このチーム情報を管理する方のコンテキストでは、
データモデリングについて
たぶんこのエンジニアリングマネージャーとかの情報って、
もともとの従業員エンティティとは中身はもしかしたらほぼほぼ一緒かもしれないが、
チーム情報の方で一人一人の従業員の情報を変更したり、
マネージするかというと違うんですよね。
あくまで参照情報として欲しいだけであって、
やりたいことはチームを管理したい。
そのときに従業員の情報をチームというコンテキストの中では、
エンジニアリングマネージャー情報という別の形なんていうのかな、
これがDCIの言葉で言うと、ロールを演じているというような言い方になるんですけれども、
チーム管理の中では、ある一つの従業員情報は、
エンジニアリングマネージャーというロール、役割を演じている情報に変化する。
別の従業員情報は、チーム管理の情報の中では、
スクラムマスターという情報の役割を演じるというような考え方ができるんですよね。
そういう見方をした方が、情報のコンテキストの中での情報の役割というのが明確になると思うんですよ。
今の考え方の話だけで、
実際、それをどういうふうに手法に適用するのかというのが、この本の中で書かれているので、
具体のところは本を読んでいただければと思うんですけれども、
そういったデータの見方、もしくはコンテキストに応じて、
どういう扱い方をするとスッキリするのかというところが一つ紹介されているので、
ここも先ほどの残骸人と比べるとちょっとマイナーかもしれませんが、
考え方を適用して、それで物事がスッキリするという、
面白い一つの例かなと思ったので、今回取り上げさせていただきました。
話したいことは本当にいっぱいある本なので、
ぜひ読書会とかあったら参加したいなとかも思ったりしておるんですが、
今日はこのぐらいにしたいと思っています。
このデータモデリングでドメインを駆動するという杉本さんが書かれた本は、
メインテーマとして、まずデータモデリングというものを中心に据えていて、
かつターゲットとしては機関系のシステムを作るときの考え方というふうに書かれているんですけれども、
聞かれた方は少し感じているかもしれませんが、
必ずしも機関系システムを作るときにしか使えないというような考え方ではなくて、
より広くシステムを作るとき、もしくはシステムを設計するときに応用できるような考え方というのがここに書かれているのかなと思っておりますので、
ぜひ広くいろいろなエンジニアの方にこの本に挑戦していただきたいなと、僕自身は強く思っています。
本の読み方
とはいえ、最初の方でこれも触れたことなんですが、いろいろな過去の業績の参照、もしくは哲学概念だとかいうことも登場してきたりするし、
機関システムなりの考え方だったり、例えば会計に関する話だとか、ちょっと経営寄りの観点の話だとかいうところも出てきます。
その辺りの理解がないと、ちょっとスッと理解できるかというと、そうではない部分もあるのかなと正直思っておりますが、
ただそういったちょっとここはよくわからないなっていうものだったり、外部参照しているものが出てきたときに、
可能であればその参照先の情報っていうんですか、例えばその椿さんのデータ中心アプローチだとか佐藤まさみさんの管理過程みたいな話が出てきたときに、
管理過程とは何ぞやというふうに、そちらの情報までたどっていって一度読んでみると。
その情報をきちんと理解した上で、またこの杉本さんの本に戻ってきて読んでみるというような、すごく深めるような読み方というんですかね。
時間をかけてそこまでして、しっかりと一語一語読み込むというぐらいの読み方をする価値のある本だというふうに思っていますので、
全部をその読み方をするのは大変かもしれませんが、例えば残概念のところだけそういう読み方をしたりだとか、
一番最後のドメイン駆動設計に対する杉本さんの考え方みたいなところだけそういった深い読み方をするとか、
いうだけでもすごく価値があると思うので、そういったところをぜひチャレンジしていただきたいなと思っておる次第です。
はい、というわけで今日は杉本慶さんの書かれたデータモデリングでドメインを駆動するという本について語ってみましたが、
本当に語りたいことが無限に出てくる、とてもいい本だと思っておりまして、
私が一人ごとを延々と語るというよりは、いろんな方とこの本に書かれていることについて議論というか、
意見交わしたりしたいなと思ってますので、そのような機会があったら読んでいただいたりだとか、
カンファレンスとかそういうところで出会ったら、この本についてぜひ私にも声かけていただけるといいなと思っています。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀之でした。
