こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
WEB+DB PRESS vol.130の特集1 「イミュータブルデータモデルで始める実践データモデリング」の第2章で語っている「2種類の複雑さ」のメガネを使って、いろんな偉い人が言ってる「複雑なソフトウェア」を見てみたい、と思います。 また、その特集の中では、アンタッチャブルにしていた業務要求がもつ「生来的複雑さ」をどうコントロールできるか、あたりまで含めてディスカッションができれば、と考えています。
会の様子
kawashimaさんからの導入その1〜複雑さとは〜
会が開かれた経緯
複雑さを解消するにはデータモデリングが重要だという話をWEB+DB PRESSでkawashimaさんがしていたところ、ちょうど複雑さについてすえなみさんが話をしたそうにしていたところがきっかけだそうです。
これまでされてきた？複雑さの定義
名著では気軽に複雑さについて話を出しているが、あまり技術書では「複雑さ」がなにかに関して正確に記載がされていないという話からスタートしました。
定義とは言えないけれど言及があるもので言うと、「A Philosophy of Software Design」では理解や修正を難しくするソフトウェア構造に関連したもので、複雑だと単純な変更でもいろいろな場所のコードを修正しないといけなくて認知負荷が高く、依存性や不明瞭さから生み出されるものだという話が出ていました。
また、「Domain Driven Design」でも矛盾が生じるものだという記載くらいであまり定義がしっかりされておらず、その後はいきなりValue Objectのような具体性の高い話になってしまっているということです。
こうした現状もあって、John Culterも3大ふわふわTweetの一つとして「シンプル」が挙げられるという話をしており、シンプルという言葉や複雑さという言葉が意味している事象は数多くありそうだという話もありました。
2種類の複雑さ
複数の役割や複数のタスク、複数の概念など、色々混ざって一貫性がない様はリッチ・ヒッキーがいうシンプルの裏返しであるため、複雑さと言えるのではないかということでした。
ただ、上記の話は納得度は高い一方で、そうではない複雑性、例えばAmazonやNetflixにおけるマイクロサービスの各サービス(=込み入っており多数の要素があって関連している状態)も複雑だと言えるよねという話がありました。
以上から、kawashimaさんは前者を単一のコンポーネントに内包される複雑さ(=Complex)として定義し、後者をコンポーネント数が多いことによる複雑さ(=Complicated)と定義しているそうです。
渡辺さんの「データモデリング入門」でも書いてあるように、この複雑さには可換性があるため、複雑さの総量を減らすことはできずとも、どちらの複雑さを選択するかは開発者に選択の余地があるということでした。*1
雑談その1
すえなみさんが複雑性について考えたくなった理由
現在分散システムに取り組んでいて、そのときに技術的な問題が原因で複雑さが生じているなら(例えばモノリスでよかったのにマイクロサービス化してしまったなど)技術的に考え直しましょうでいいんだけど、業務の複雑さが露呈しているならどうしようもない部分も出てくるよね、と考えているそうで、この判断をどうするのか？について議論したくなったそうです。
DBは技術として枯れているので共有したくなるけれどDB共有はアンチパターンと言われがちで、それがなんでなのかあまりわかっていない
DBを共有したいならそもそも分ける意味がないよね、という話で、DDDの境界づけられたコンテキストの考え方ではなく技術的な観点で分割するとアンチパターンになってしまうという話がありました。
例えば、アナログ時代はどういう風に業務を回していたか？みたいな観点で業務フローを洗い出してそのフローを活用しながらサービスを分割していくのはいいが、そうではなく技術的な観点(デプロイ高速化...)でマイクロサービスを活用してしまうと失敗してしまうということです。
インフラ技術は進んできてコンテナ作成などにかかる手間は少なくなり、論理的にデータを分けるコストと物理的にデータを分けるコストは少なくなってきているものの、技術的な観点での分割に傾倒しているのは危険な場合も多いということです。
マイクロサービスは自律分散だというけれど中央にデータ管理しているCTO的なものはあるのでは？
「分散したからにはクライアントアプリケーションは自由に振る舞うべき」という話が出ているけれど、これはあくまでもサブドメインに関して言えることが多い話で、コアドメインに関しては必ずしも当てはまるわけではないよね(場合分けが雑すぎる)という話が出ていました。
自律分散という言葉に踊らされて、クライアントに話を自分から取りに行くべきだった場面で取りに行けていなかったのかなあという反省(?)もすえなみさんから出ていました。
偽装のComplicated
Complicatedかというとそうではないけれど、中央集権的な考え方ではなく個々のアプリケーションに任せてしまっているが故にComplicatedに見えてしまうというのはあるよね、という話がありました。
「Release it!」でも、新米アーキテクトは箱自体に注目してしまうがベテランアーキテクトは箱と箱の関係性に注目するという話もあるため、まさにそういった議論なのではないかということも雑談の中で出ていました。
kawashimaさんからの導入その2〜生来的複雑さを設計する〜
生来的複雑さをもたらす柔軟性
「Analysis Patterns」では、システムに柔軟性を持たせ過ぎてしまうと複雑さが増大して破綻してしまうという話があったり、「Clean Code」で複雑さを整理するためには神クラスではなく適切な引き出しを持ったクラスが必要という話があるように、従来から柔軟性と生来的複雑さのトレードオフがあるよね、という部分から話が始まりました。
柔軟性と複雑さのトレードオフ
柔軟性と複雑さにはトレードオフがあるよね、という話がありました。
例えばPizzaのモデルであれば、
Cheese Pizza(price/cheese)→Pizza(price/dough/topings)→Product(price/Ingredents)
という風にモデル遷移していくにあたって、表現できるピザの種類はどんどん増えている一方で複雑さはどんどん増えているよね、という話が出ていました。
ピザの例で言うCheese Pizzaのモデルに対する批判
以下の2点が批判として挙げられるということでした。
- 仕様変更時にプログラムがの修正が発生して、そこにつられてテーブル変更も必要になってくる
- 設計自体が抽象的思考に至りにくく、水平思考につながらない
ピザの例で言うProductのモデルに対する批判
以下の2点が批判として挙げられるということでした。
- 多くの制約が存在するが、その制約のテスト容易性は低い。
- 現時点には不要な複雑さを導入している。(ピザとちょっとしたサイドメニューしかない店でこのモデルは過剰設計になっていないか？)
雑談その2
ユースケース駆動と水平思考
すえなみさんは、ユースケースに駆動されてユースケースが増えるたびに新しいものができるのはあまり気持ちよくなく、水平思考につながらないというのは結構大きな問題だと考えているという話をしてくれました。
行き過ぎた柔軟性
パッケージ製品で、カスタマイズして都度テストもして...のような開発になるように設計していた行き過ぎた柔軟性の話がありました。*2
これに関連して、プログラマーの中だけで良し悪しを語っているのは非常によくないよね、という話も出ていて、プログラマーの考えがビジネスに反映されてしまう今の時代では「これできないと思っていました」みたいな発言がビジネス上で平気で出てしまうのは怖いよね、という実体験？も出ていました。
Cheese Pizzaのモデルに振り切られがちなイテレーション開発
すえなみさんの感覚的には、限られたイテレーションでデリバリーするときにどうしてもCheese Pizzaのモデルに振り切られがちで、対業務側よりも対エンジニア側のほうが話をするのに苦労することが多いということです。
設計の工夫
副業やフリーランスが市民権を得てきたので、Complicatedだけど各々がシンプルというのは良い時代になってきたのでは？という話がすえなみさんからありました。
そんなこともあって、すえなみさんはそれぞれが自分のペースで作業できるようなアーキテクチャが許容されつつある時代になってきているのかな？という話もしてくれました。
一方でkawashimaさんは、炎上したときに助けてもらいやすいように設計をしようとSIer時代は考えられていたそうで、立ち上がりの速さを上げる工夫や一貫性を保つ工夫をされていたそうです。
会全体を通した感想
終始まったりとした感じで進み、リラックスしながら楽しく聞くことができました。
会の本筋から少しそれた話題では、「Manage it!」や「空想プロジェクトマネジメント読本」何冊か初めて聞くような本も出ていて、積読が増えたのもよかったです。
少し古めな本のようですが、早速読んでみようと思います。
