生き様081. DDDは現場の課題を解決するか？

マネジメント | 学習

» 2021/03/04

お取り寄せが止まらないッ！！

関東圏以外での緊急事態宣言が解除されました。
それぞれの自治体で独自に警戒宣言等を続けている地域もありますが、
僕は「GWぐらいまで続くだろう」と予想していたので、早い解除だと感じています。

先日、チョコの食べ過ぎで一部の方から体重を心配されたのですが。
実は各地の名産品のお取り寄せも楽しんでいます。
これも体重増加の原因なのでは…？と心配しつつ、止まりません。
中でも、最近お取り寄せした『シンカンセンスゴイカタイアイス』。
コレが感動モノだったので、動画にしてしまいました。

マンスリー技術コラムです

第一木曜日は技術について話すことに、先月からしました。
やはり、ITエンジニアの集まる場ですね。
結構な反響を頂いていた気がします。多分。きっと。気のせいでなければ。

今回も、（僕に）無理のない範囲で、IT似関連する技術のお話をしていきます。

みんな大好きDDD

前回の日本語プログラミングは「技術的なことを書こう」と思ったきっかけです。
今回取り上げる1ドメイン駆動設計（以下、DDD）は、技術の話を定期的にしようと決めたきっかけです。

今更DDDについて、歴史的な経緯やどう取り組むべきか等の話をしません。
それは既に、多く語られているからです。
それ以上に、僕がDDDの実践者ではない、ということが大きいのですが。

DDDについて理解したい人は、あるエリック・エヴァンスの書籍を読みましょう。

原語本の出版から約18年。
日本語版の出版からもうすぐ10年が経つこの書籍に書かれている内容は、
日々衰えるどころか、高まっていってき、広まっています。

ですが「その根本的な部分については、誤解が多く広がっている」。
僕はそう感じています。
僕よりすごいDDDの実践者の人達が、日々そのことについて発信しています。
それでも、隅々まで行き届いていないのが実情です。
微力ながら、その一助に成れればいいな、と今回のコラムを書いています。

DDDは現場の課題を解決しない

僕が根本的な誤解を強く感じる言葉があります。

「DDDが現場の課題を解決する」

DDDはプログラミング技術ではありません。
同じく、DDDはシステム設計技術ではありません。

ユビキタス言語や関心の分離、ビジネスドメイン等、刺激的な概念が沢山含まれます。
しかし、そのどれもが「現場の課題を解決するためだけ」のものではありません。
解決しない、とは言いませんが「その為に用意されたものではない」のです。

DDDの本質は、マネジメント技術です。

要件定義から、テスト工程まで使える一気通貫的な単一モデルを作ることで、システム構築における各工程で一貫性を持たせる

これがDDDのキモで、DDDを導入することで得られる最大の効果だと考えます。
単一モデルを作る過程の成果で、そして単一モデルがあることにより、各工程での問題の発生量を抑えたり、解決に掛かるコストが軽減されたりするのです。

先程唱えた幾つかの用語も、全てはこの単一モデルを作るためのものです。
作られた単一モデルをコンピューター上で動くシステムとして再現するための手法です。

DDDは、システムのライフサイクルの中における、様々なコストを低減するでしょう。
ですが、短期的に、目の前にある開発の、主にプログラミングの工程を楽にするものではないのだ、と僕は理解しています。

あえて冒頭の言葉に沿って言葉にするなら

「DDDはシステムのライフサイクルにおける様々な問題への対処能力を上げる」

だと考えています。

間違ったDDDと軽量DDD

「DDDを導入した結果、プログラミングコストが上がった」
「DDDは値一つごとにクラスを作るから非効率的」

これらの指摘は的外れです。

前者については、既に前の項目でお話しています。
注目すべきは、プログラミング工程のコストだけではありません。
テスト工程やメンテナンスやリプレイス等、先々を見据えたコストを考えるべきです。

極論、新規開発時のプログラミングコストだけを言うならば要らないものだらけです。
アジャイルな開発も、標準化もリータブルなコードも、ソースコード管理も要りません。
各々のプログラマーが手癖で好きな様にコードを書けば良いんです。
それがどういう結果を産むかは、想像に容易いですよね。

「DDDは値一つごとにクラスを作るから非効率的」という指摘に目を向けましょう。
これは、ValueObjectへの指摘であり、DDDへの指摘ではありません。

ValueObjectは、オブジェクト指向の延長線上の技術です。
記法と言っても良いかも知れません。
また別の機会に話そうと思いますが、ハンガリアン記法に通じるものもあります。
悪名高いシステムハンガリアンではなくて、アプリケーションハンガリアンの方ですよ？
ValueObjectの真髄は、オブジェクト指向の「カプセル化」を進めたものです。
値だけではなく、関連する処理も集約することで、型の役割を凝縮するものです。

DDDで作られた単一モデルを表現するのに、ValueObjectの考え方が都合良いだけです。
【DDD＝ValueObject】ではありません。
ですから動的型付けの言語で開発しているプロジェクトでも、DDDは運用できます。

ValueObject等の技術的な部分を導入した「軽量DDD」という開発手法もあります。
ただ、僕は「軽量DDD」を「DDD」としたくないですが。
関心の分離や、役割の集約等で、DDDっぽい雰囲気を感じることはできます。
ただ、それはDDDの真似事です。
また、DDDの導入に備えるスモールステップとしては有効に働くでしょう。

「DDD」はマネジメントの技術なのですから、開発の現場だけで完結する「軽量DDD」は「DDDたり得ない」というのが、僕の見解です。

余談ですが、僕は堂々と『真似事としての軽量DDD』を取り入れています。
基本的に一人での開発になる仕事なので、好き放題やっちゃっています。
オニオンアーキテクチャと組み合わせて結構コードの取り回しが良くなるのです。
ですから「軽量DDD」自体を否定するつもりはありません。

最後に

何故実践者ではない白栁が、こうもDDDを語ろうとするのか、についてお話します。
言い訳かもしれません。

先程自分で述べた通り、僕はDDDの実践者ではありません。
エリック・エヴァンスの本を読み込んでいるとも言えません。

ですが、僕はシステム開発の実践者です。
要件定義からテスト工程まで、様々なフェーズのシステム開発に関わった実績があります。
その中で経験したトラブル、その中で得たノウハウ、感じた様々な事柄があります。

それらは、僕の中の血肉として「システム開発かくあるべし！」的な哲学になっています。
僕の哲学とDDDの唱えるところは、とても近いと感じています。
流石に「DDDが僕と同じこと言ってる！」なんて偉そうな戯言は宣いません。
多くのシステム開発に関わる人が感じていることに対して、ひとつの答えがDDDだった。
僕はそう考えています。

DDDがすべてを解決するとは言いません。
しかし、使うべきところを定め、足りない部分は他の手法と組み合わせていけば、
その先には、より効果的なシステム開発の方法が見えてくるはずなのです。

おまけ１：本当のDDDはエリック・エヴァンスの中にしか無い

かなりアレな話になりますが、僕は技術を宗教と同一視しています。

宗教の偉大な教祖は、得た真理を言葉や経典という形で教えを残します。
そして、その弟子達はそれを手掛かりに自分の解釈で真理へ至ろうとします。
後世、幾人かの弟子が真理にたどり着いたとして、それは教祖と同じものでしょうか？
僕は違うと考えています。それぞれの真理にたどり着いたのだと。

技術も同じです。
ある技術者が唱えた技術が体系化され書籍に残ったとします。
色々な人がその技術を研究し、再現し、導入していくでしょう。
ですが、本当の技術は、最初に提唱した技術者の中にしか無い、と考えています。

僕はその例を、ハンガリアン記法に見ています。
カール・ロジャーズの非指示的療法が広がる際にも、同じことが起こっています。

つまり、僕が大好きな傾聴や来談者中心療法も、本当はロジャーズの中にしかない、と。
僕らは前例を頼りに、それぞれの技術を磨くべきであり、完全再現はできない、と。

DDDについても、同じだと考えています。
「本当のDDDがこれだ！」なんてエヴァンス以外に言える人はいません。
ですから、語るべきは、DDDの忠実な再現方法ではないのです。
残してくれた手掛かりをベースに、自分の周囲に落とし込む方法なのですから。

おまけ２：DDDのイメージを作るための書籍

エヴァンス本は、よく出来た本ではありますが、はやり訳本です。
なので、読みづらいという感想を持ち、嫌う人もいます。
また、もう少し実践的なコードの書き方に興味を持つ人も多いでしょう。
そういう部分に効果的な本があります。

僕は普段C#での開発が多いですから、この本のサンプルコードはとても嬉しいです。
また、文法がよく似たJavaや、Javaから派生している他の言語を使う人にも、ちょっと頑張る必要がありますが、イメージできるものでしょう。
エヴァンス本の手引きとしても、とても優秀です。

2021年ITエンジニア本大賞の技術書部門のトップ10にもランクインされています。
とても良い本だと思いますので、是非読んでみて下さい。

また、どうしても…という人向けに、この本の元ネタとなったWebページもあります。
こちらのページを読んでもっと深く知りたい、と感じたなら書籍を買うのでもいいかもしれません。
ただ、錚々たるDDDの実践者達の意見を取り入れて大幅にボリュームアップした書籍の方が、今紹介したページよりも何百倍もすごいものになっている、と断言できます。

以上！

---

ミニコーナー：こちらヤマネコシステム技術部三課！

ここは日本のどこかにあるかもしれない「ヤマネコシステム」社。
そこはかとなく、ブラックの香りがするこの会社の日常を、少し覗いてみましょう。

花粉症

ヒノモト	「あれ？オラフ先輩、眼鏡ってめずらしいですね。コンタクトでしたっけ？」
オラフ先輩	「ああ、花粉症でツライからね。花粉ゴーグルだよ」
ヒノモト	「なるほど。みんなマスクしてますからね。花粉症って判り辛いですね」
オラフ先輩	「毎年薬飲んでマスクしてればそこまで酷くはならないんだけどね。今年はダメ」
	「今年は例年以上に症状でちゃってるからサ。少しでもって」
ヒノモト	「大変ですね。僕は花粉症じゃないんでわからないですけど。お大事に」
オラフ先輩	「おぉぅ？それは花粉症じゃない自慢かぁ？？ナンダコノヤロー」
ホンドくん	「ヒノモト、『花粉症ハラスメント』ってのもあるんだ。気を付けた方がいいぜ？」

（つづく）

---

ITエンジニアの視点で、時事ニュースを5分間で紹介する動画を平日毎日公開してます。
「日々の生活の中にエンジニアリングがある」からこそ、
身近な時事ニュースから学ぶことが重要です。

#ほぼ日ITエンジニアニュース

火曜日に公開した動画ですが、週末のみずほ銀行のオンラインシステムトラブルを扱っています。
この一報を目にした時、僕は関係者でもないのに胃が痛くなりました。
人々の生活を楽にするシステムが、色々な人を不幸にしてる…。

トラブルの害に遭われた方、関係するITエンジニア諸氏、対応した窓口やオペレータの方々には、心よりお見舞いを申し上げます。