「ドメイン駆動設計」は新人SEの必修項目でいいと思う
import HeadingBand from “@/components/markdown_components/HeadingBand.astro”; import Tip from “@/components/markdown_components/Tip.astro”;
何をやらせても3日と続きやしない私がブログを3日連続で書いている時点で、空からヤリが降ってもおかしくないこの年度末、皆様いかがお過ごしでしょうか。
最近すっかり拙著ネタばっかりになってしまいましたが、急に「昨日はengine.ioいじって挫折してました」とか書いても話題が飛びすぎるので、書籍つながりで**ドメイン駆動設計(DDD)**について個人的な意見を書いてみたいと思います。
一部の方には釈迦に説法になってしまうかもしれませんが…
ドメイン駆動設計(英: Domain-driven design, DDD)とはソフトウェアの設計手法であり、
‘複雑なドメインの設計はモデルベースで行うべきであり’、
‘また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき’
とする
乱暴にまとめれば、**「良いソフトウェアを開発するには、(コンピュータや技術も大事だけど)ドメインがカギだよ」**という考え方です。
しかし、肝心の「ドメイン」というものが、また慣れるまではイメージしにくい用語で困りものです。
本来「ソフトウェアが実現しようとしているものごとの対象領域」を表す概念のことですが、私の場合、はじめての方には「あるソフトウェアが人に代わって担おうとしている、現実世界の一部分」と説明することが多いです。
たとえば、「自動券売機(の中のソフトウェア)」は、もともと駅員さんが手作業でやっていた「駅における切符の販売業務」というドメインを自動化(オートメーション)するためのものです。
そして、このドメイン駆動設計という教えは、
「もしキミが本当に良い自動券売機ソフトウェアを書きたいなら、
JavaやC言語やRubyやJSやGoや以下略 に詳しいことも大事だけど、
駅における切符の販売業務がどんなものかについても
詳しくないといけないよ。」
と諭してくれている――そう私は理解しています。
このDDDについては、DDDを提唱したEric Evansが著したその名もずばり「ドメイン駆動設計」という本が有名です。
いわゆる中上級以上のプログラマの方やアーキテクト的な役割を果たされる方は、お持ちの方も多いのではないでしょうか。
ただまぁ、「変形A4で576ページの充実っぷりと重量感、お値段は5460円」というスペックからして、入門者の方にはちょっとキビシイようにも思います
そんなこんなで「DDD」という言葉は、エンジニアが人前で口に出してみるだけで多少中上級者感
DDDは、『入門者にこそ有用な概念』
という感覚を持っています。
新入社員さんや若手のエンジニアのオブジェクト指向言語の学習のお手伝いをする場合には、必ずこのエッセンスを中核に伝えるようにしています。例外はありません。
もちろん、DDD本の576ページの内容すべてではありません。
DDD本でいうと第2部(レイヤ化、モデルパターン、ライフサイクル)あたりが具体的な方法論の印象を持たれる方も多いかと思いますが、私が最も重要視するのは、第1部冒頭の「ソフトウェアの核心」、そしてエピローグにある次のようなDDDの「価値観」です。
(ドメイン駆動設計を行っているプロジェクトの)
決定的な特徴は、対象となるドメインを理解し、その理解をソフトウェアにおいて具現化することを、重視するところにある。
通常、DDDという用語は用いず平易なことばで説明するので、聞いている側は「今、自分がドメイン指向について学んでいる」とは思ってもいないでしょうが…。
DDDの基本思想は、私たちが普段納期や学習カリキュラムに追われ見失いがちな「ソフトウェア開発で何を大事にすべきか」について、明確な拠り所を与えてくれます。
特に、プログラミング言語を初めて学ぶ段階で、この基本思想に触れておくことにはたくさんのメリットがあると感じています。
理由1: 学ぶことを楽しんでもらいやすい
「ドメインからソフトウェアを考える」というアプローチでは、巨視的にドメインをどう捉えるかという観点に重きが置かれるため、そこそこの規模や複雑さであれば、むしろ「ドメインをモデルとしてどう表現してやろうか」という楽しみを誘導しやすように感じます。
ドメインをお手本にしながら、コンピュータの中のまっさらな舞台に、自分の裁量で「登場人物」をおいていき、自分が書いた「脚本」にそって動かしていく感覚が、より楽しみを引き出しやすいのだと思います。
楽しいと感じているとき、人はもっとも学習効率が高い
という法則は、科学的にも経験則としても良く知られていることですし、入門者にこそ「プログラミングの楽しみ」と出会って欲しいですよね。有望な能力をもった人が「面白くない」「辛い」という理由で挫折することは、社会にとっての大きな損失だと思います
理由2: 「何のためのソフトウェアなの?」に立ち返れる
プログラミングをはじめて学習する人の中には、文法を覚えることや、コンパイルを通すことや、プログラムを動かすことに必死になってしまう方がいます。
そして時に、そこがゴール(目標)になっちゃってる。
たしかに基本文法(ifだのforだの変数だの)を学んでいるときは文法が大事ですが、それを卒業したら、新入社員だろうと、もっと高い次元に目を向けてもらえたらと思うのです。
そもそも「ぼくらは、何のためのソフトウェア作るの?」
決して、コンパイルを通すことが目的ではなくて、
あるドメインをITによって実現
じゃぁ「ぼくらエンジニアの仕事は何なの?」
決して、プログラムとかシステムを動かすとかということではなくて、
社会やお客様や自分が望む「理想のドメイン」をITで実現することですよね。
このようにして学び手が自分の中で定める目標を「プログラム言語をマスターする」から、「理想のドメインを実現し、誰かの役に立てるようになる
理由3: 長く使える財産になる
よく「新入社員がプログラミングを学ぶ場合、どの言語が良いか」という話題でスレッドが賑わったりしますね。
- とっつきやすさ
- 日本語情報の多さ
- 実務での利用頻度(業務必要性)
- トレンド
などなどありますが、個人的に若い学び手のお手伝いをする場合は「学ぶことで、長く使える財産が残ること」を大事にしています。
RubyやらJavaやらの基本文法を覚えることや、本を見ずにそれをスラスラ書けるようになることには大して価値を見いだしていません。きっと10年後にはまた違う言語が出てきていて、文法もいろいろと変わっているんだと思います。
その点「ドメインと技術の両方を意識したITの使役」というDDDの基本思想は、ITに関わる仕事をしていく以上、いくつになっても、PMやコンサルや営業職になっても、役に立つ財産になるのではないかと思います。
さて、そんな私がこのような個人的趣味嗜好を拙著『スッキリわかるJava入門 』に持ち込まないはずがないわけでして…。
この本を初めて読むという方に手渡してパラパラっと眺めて貰うと、
- イラストが多い
- 雰囲気がやわらかい
- ちょっと幼稚な感じがして照れる
など、いろいろとご感想をいただくのですが、一番嬉しかったのは、次の言葉です。
「(ニマっ・・・)へぇ、OO
オブジェクト指向のこと の概要とDDDだけで1章割いてる入門書って、珍しいっすね」
この本では、第7章から第13章までがオブジェクト指向の学習にあたるのですが、その最初の章を「ドメインとソフトウェアの関係」を紹介し、明確化し、イメージしてもらうための内容にしました
この章のおかげで、以降のオブジェクト指向の章も楽しくやさしく理解できますし、DDDの基本思想を当然のことのように学ぶことになるという算段です
入門書って、結構せつない一生を送ることが運命づけられた本です。
期待と不安を抱えた読者の方とある日出会って、「はじめて学ぶ苦楽」をともにできる一方、そのうち学び終えた読者の背中を見送りつつ、自分は捨てられなければなりません。
いつの日かこの本が役目を終え、”無事”忘れられる日がきても、学び手の中に「技術とドメインの両方を大事にする」という気持ちだけはずっと残るといいなと思っています。
参考
このブログ記事は、著者の個人ブログ(flairDays)から移転掲載されたものです。




