下記本を読んでみたので気になった部分のまとめなど
そもそも本書で定義している Web 世代とは何なのか
オープンシステム世代の次を Web 世代とする。
オープンシステム世代の前はメインフレーム世代。 以下の区別は 書籍 p195 より抜粋
世代の話はどこかで公式の定義があるわけではないので、深くはつっこまない。あくまで話していく上で本の定義はこうですという紹介までに留める。なぜなら、人によって解釈が異なる部分だし、何が何世代と決めることに意味はないため。新しく世代を定義すれば目新しさやマーケティング的なメリットがあり浸透しやすさはあるように思える。Web3や芸人第7世代など。。
私は、本書が Web 世代が知らないエンタープライズ設計 とされていたので Salesforce のようなエンタープライズアプリケーション、あるいは 大規模 BtoB の設計が学べるかと思っていたが違った。企業情報システムの設計手法 や 仕事の進め方 にフォーカスがあたっていて、技術的な内容はほとんど紹介がない。私のようなサービスの設計開発をやっているエンジニアにはそこまで参考にするところがなかった。対象読者はわりと経験の浅いシステムコンサルタントや SI に勤めている人なのかなと。SaaS 開発など、アジャイルでデータモデリングのような設計フェーズに携わっている方にはものたりないと思った。
ちなみに、企業情報システムとは関わるアクターが 3 以上のシステムを指していた。例えば、複数部門がつかったり、コロナワクチンアプリのように行政、会場運営、ユーザーなど複数の登場人物が出てくるものも考えられる。アクターが3以上というのは大概大きくなってきたサービスには当てはまるので定義は広いとは思うがそういうものだとする。
勉強になったのは、DDD の解釈のところであるアクターの立場、視座をコンテキストと呼び、コンテキストを前提とした語彙集をユビキタス言語というところ。例えば、ECにおいて物流部門の注文と商品部門の注文、ユーザからみた注文は異なる場合が多い。そのため、この例では注文に対してそれぞれのコンテキストでユビキタス言語を定義する必要がある。そして、コンテキストの境界ではドメインの分割ができる可能性が高い。ここを意識してモジュール設計を行えば凝集度が高められるはず。大きくなったコンテキスト部分については必要に応じてサービスの切り出しを行える。
また、一つ外側のスコープを意識してデータモデルを作るということは意識しようと思った。最近は大きいゴールに対してフェーズを切って登っていく開発なので自然と変更には弱いわけではない。ただゴールに達してもそれより後の世界では大幅に構成を変えざるを得ないとなるとモデリングがよくなかったという結論になりそうなので、できれば一つ外側の世界に広げられるように頭を動かしておきたい。単純な例で言えは、企業モデルを作ったときに、企業が複数の仮想企業を持てるようにするなど。AWS Organization のような概念。またはあるモデルに対して翻訳をどうするかなど。
UI 偏重でシステム開発をするデメリット
UI は重要だが、その後ろのデータストアも重要。UI をベースにデータモデリングをしてもいいとは思うが、要件を元にデータモデリングをしたほうが変に UI に引っ張られずに済むのでよりよいモデルができるのではないかと思った。データモデリング自体は、フロントエンド・バックエンド問わずシステムとしての理想形を探す作業なので UI がなくてもできる。そこで認識を合わせてから使いやすい UI へのモデリングに移せばよいのではないか。よく考え、ときにはスコープを広げたモデル図は今後のシステムの進化にも役立つはず。