現場で役立つシステム設計の原則

2025年6月18日読了

Credit

増田亨. (2017). 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践方法. 技術評論社.

Summary

長期的な業務アプリケーション開発において高回転の開発を楽で安全に行う原則を解説した本。

Note

ミドルレベルの設計書が読みたかったので読む。コーディングにおいて、ミクロなテクニックは『リーダブルコード』等が、マクロなテクニックは積読しているけど『ソフトウェアアーキテクチャの基礎』みたいな本がある。言語ごとのテクニックは『Effective C++』等々がある。が、コードの汎用性・保守性・可読性を高めるために、どんなデータ構造や関数を定義・利用するかというレベルの設計に関する文書があまりに少ないように思える。デザインパターンと同レベルの議論だが、俗に言うデザインパターンはオブジェクト指向でのものばかりで、一般性がない。そこで『良いコード/悪いコードで学ぶ設計入門』という良い感じの本を見つけた。が、何やら評判がよろしくないので、代替として提示されていた本書を読むことにした。https://qr.ae/pAebtz

こういう本を読むたびに、会計システムなんて作らないんだよなあ、バックエンドだったらその例で良いけどさあ、と思うのだが、例えばゲームエンジンのようなフロントエンドとも密接に関わるプロダクトの例はないものかね。

一章は、ドメインに対応した型・及びその上に不変な操作を定義して、安全性を高めようというもの。何か変えるたびに新しいコレクションを返すというのはパフォーマンス的に気が気じゃないが……。Rustなら所有権奪って弄って返せば良いね。

二章はとりわけ学ぶことなし。ただ、オブジェクト指向に触れると毎回、Rustでも露骨にオブジェクト指向で書けたらなあ、と思う。あるいは、C/C++ライブラリの宣言が読めて、C++くらい爆速な、モダンなオブジェクト指向言語があればなあ、と思う。Zig with Classesが欲しい。

四章はDDDで開発をする上での諸注意。正直、ここに書かれているアプリケーションの複雑度はぼくが普段書いているGUIアプリケーションやフルスクラッチゲームの複雑度に比べれば足元にも及ばない(非同期の排他処理に気をつけるくらいか)ので、何を解説されても全く理解できなかった。そりゃそう設計するだろ。の気持ち。これはぼくが新参プログラマだからDDD的な思考が無自覚に染み付いているのか、単に腑に落ちていないのか。例えば、弾幕STGにおいて、キャラクターを動かして弾を避ける「回避」という「コト」に着目したとき、本当にこの本通りの設計になるか？　入力があって、移動量があって、被弾したか否かという結果を得る。そんなことはない、キャラクターの移動は各フレームに一回しか許されず、かつ回避以外の色々なコトに波及する。回避のためにキャラクターを動かすのではないし、キャラクターが動いたときそれは必ずしも回避を意味しない。だとすると回避とは、動き終わったキャラクターと動き終わった弾が重なっていないことのみを意味し、それはデータの比較であってそれ以上のことはない。矢張り、DDDは「この手の」アプリケーションに使える考え方としか思えない。

そういう批判があったのか、著者がゲームにおけるDDDを解説していた。https://www.slideshare.net/masuda220/ss-111011089 うーん、違う、求めていたものではない。まあDDDはともかく、この本や俗に言われるDDDのパターンはオフラインゲーム開発には使えないんだろうな。ゲームはゲームでECSとかあるし、そういうのを学んだ方が良いのだろう。

五章はアプリケーション層の解説。アプリケーションサービス→サービス。なるほど。プレゼンテーション層、ドメインモデル、データソース層を繋げる層。サービス？　なるほど。「契約による設計」という言葉が登場した。このメソッドはこのメソッドが呼ばれた後に呼ばれる、という決まり事を実際に守っているかどうかはコードに書かなくて良い。まあ確かにその通りだよな。自分はコメントに書くに留めているけど。それで良いらしい。

以降は「せやんな」という内容。特に思うことはなし。

読了して思ったことは、

• 1マイクロ秒どころか1ミリ秒を争う世界の話はしていない。とにかく開発の持続可能性の話だった。言い換えると、一度作ってしまったら終わりのプロダクトではなく、作り始めたら一生メンテナンスしなければならないサービスのための話。
• 当然ながらゲームなりツールなりの開発に役立つ部分は少ない。ただ、オブジェクト指向もドメイン指向も素晴らしい考え方であることに違いはない。本書通りには行かないが、模倣できるところは模倣したい。
• 一度は日本語命名でコーディングしてみたいな。今作ってるゲーム、Rust製なんだけども、識別子に日本語は使えるのかしら。

Impression

読み始めたときの期待とは違った。 頭が整理され、かつ効率も良い、オブジェクト設計の正解のようなものを探していたが、そういうものではなかった。 むしろ、パフォーマンスは深く考えず、とにかく時間が経とうとも・人材が入れ替わろうとも持続可能であるプロダクト開発の心得を紹介するものだった。 なんだかそういう所謂Webサービスのハウツーが巷に溢れ返りすぎていて、あまり興味のない自分にとっては「違うんだよなあ……」となってしまう。 とはいえ、そもそも全く異なる期待をしてしまったのは、「良いコード悪いコード」本と同列のものと勘違いしたのが原因なので。

オブジェクト指向はもちろん、ドメイン指向はとても良い考え方だと思う。 プログラマもマネージャも、そのプロダクトのドメインを把握して、それを各種実装に落とし込むべき。 あまりに当然すぎる。 ツールを開発しているなら自分でもそのツールを使いなさいと。 ゲームを開発しているなら自分でもそのゲームをやりなさいと。 ドメイン指向開発の本質はそこだと思う。 マシン優先ではなくて、コード優先でもなくて、ドメイン優先であると。 まあ、1ミリ秒が惜しいプロダクトではそうは言っていられないので、本書で書かれていたことがそのまま実践できるかと言えば、難しいところがあるが。 あまり興味がなくて手を出せなかったWebサービスのレイヤードアーキテクチャ周辺やらドメイン指向の本質を学ぶことができて有意義であった。

■