Angular v8=>v10でビルド時間とファイルサイズがどのくらい変わったか見てみる
はじめに
先日、ng-japan OnAir で Angular 8→9→10→11でビルド時間がどれくらい早くなっているかみてみよう!という記事が紹介されていた。ちょうど去年末に仕事であるプロダクトのAngularバージョンをを v8.0.3 から v10.1.6 に上げたので、ビルド時間とファイルサイズに変化があるか比較してみた。
前提
- Angular v8.0.3からv10.1.6へのバージョンアップ
- Angularバージョンアップ以外の変更も入っているので完全に純粋な比較にはならない
ファイル数、ステップ数の比較
ひとまず、どのくらいの規模のコードかを確認する。
ファイル数やコード数差分はあるが、大きな差はないと言って良いと思う。
AngularCLI: v8.0.3のブランチ
$ cloc src 1317 text files. 1307 unique files. 28 files ignored. github.com/AlDanial/cloc v 1.88 T=1.32 s (985.4 files/s, 47881.5 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- TypeScript 1053 5578 3772 42158 HTML 144 246 98 5767 JSON 27 1 0 3867 Sass 74 275 75 1542 Markdown 3 7 0 17 CSS 1 0 0 4 SVG 3 0 0 3 ------------------------------------------------------------------------------- SUM: 1305 6107 3945 53358 -------------------------------------------------------------------------------
AngularCLI: v10.1.6のブランチ
cloc src 1312 text files. 1302 unique files. 27 files ignored. github.com/AlDanial/cloc v 1.88 T=1.50 s (866.0 files/s, 41973.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- TypeScript 1049 5510 3913 41724 HTML 144 246 98 5776 JSON 27 0 0 3866 Sass 74 275 75 1541 Markdown 3 7 0 17 CSS 1 0 0 4 SVG 3 0 0 3 ------------------------------------------------------------------------------- SUM: 1301 6038 4086 52931 -------------------------------------------------------------------------------
npm run start(ng serve)の比較
まず、ng serveの比較を行ってみる。
FYI: ng serve
- Angular CLI のコマンド
- アプリをビルドして提供し、ファイルの変更時に再構築する
AngularCLI | 1回目(ms) | 2回目(ms) | 3回目(ms) | 4回目(ms) | 5回目(ms) | 6回目(ms) | 7回目(ms) | 平均(ms) | totalsize |
---|---|---|---|---|---|---|---|---|---|
v8.0.3 | 35926 | 35959 | 35202 | 33241 | 32628 | 31417 | 32628 | 33857.28571 | 14.70796MB |
v10.1.6 | 38152 | 42009 | 35475 | 33636 | 33272 | 33262 | 33795 | 35657.28571 | 12.741MB |
total size が約2MB小さくなった 🎉🎉🎉🎉
約13%の削減 🎉🎉🎉🎉
npm run start(ng build --prod)の比較
次にng build --prodの比較を行ってみる。
FYI: ng build
- Angular CLI のコマンド
- Angularアプリをコンパイルし、デフォルトでは、現在のプロジェクトの
dist/
という名前のフォルダーに出力を書き込む --prod
オプションを指定すると本番用の設定でビルドされる
AngularCLI | 1回目(ms) | 2回目(ms) | 3回目(ms) | 4回目(ms) | 5回目(ms) | 6回目(ms) | 7回目(ms) | 平均(ms) | totalsize |
---|---|---|---|---|---|---|---|---|---|
v8.0.3 | 79276 | 55032 | 57331 | 57013 | 57365 | 53708 | 56277 | 59428.85714 | 3.87166MB |
v10.1.6 | 79718 | 46298 | 45161 | 45029 | 46713 | 46631 | 46272 | 50831.71429 | 4.30434MB |
ビルド時間の平均が約9秒ほど早くなった 🎉🎉🎉🎉
約14%の削減 🎉🎉🎉🎉
webpack-bundle-analyzer の結果を比較
webpack-bundle-analyzerで出力結果の比較をしてみたが、結構差分があってぱっと見比較できるような状態ではなかった。プロダクトのコードということもあるため、画像は割愛する。
webpack-bundle-analyzerの出力結果が異なるのはdevelopにAngularバージョンアップ以外の変更が入っているためである。少なくとも、tsconfig.jsonのtargetの変更が影響している。
tsconfig.jsonの差分
参考までに、tsconfig.jsonの差分をまとめておく。
AngularCLI: v8.0.3のブランチ | AngularCLI: v10.1.6のブランチ | |
---|---|---|
target | es5 | es2015 |
lib | es2017, dom | es2018, dom |
module | es2015 | es2020 |
target
TypeScriptは最終的にJavaScriptにトランスパイルされる。このオプションはそのときにどのバージョンのJavaScript向けに出力するかといったものである。
lib
使いたいtargetには使いたい機能がない、でも使いたい。そのような時はlibオプションを指定することで使うことができるようになる。
module
このオプションは出力されるJavaScriptがどのようにモジュールを読み込むか指定する。
まとめ
- 一定の改善が見られた🎉🎉🎉🎉🎉🎉
- そもそもAngularバージョンアップ以外の差分や設定変更もあるので、純粋な比較にはなっていない( ; _ ; )(webpack-bundle-analyzerの結果を見ても単純な比較ができない)
- 今度はバージョンアップだけの差分でチェックしてみたい
- webpack-bundle-analyzerよりsource-map-explorerの方が正確らしいので試してみたい。
- Angularチーム推奨。理由は、AngularCLIが webpackを内包しているが、webpackが出力するstats.jsonに埋め込まれている情報だけでは、Angularが最終的に最適化した結果を反映できていない部分があるため。SourceMapには全部つまってるから、そっちをみた方が正確とのこと。
参考
おまけ
半年ほど携わっていた大きめのプロダクトの場合
こちらはAngularのバージョンアップの比較ではなく、単純にビルド時間とファイル時間を出しただけだが、コード量が多いものだとどのような結果になるのかを見てみたくてやってみた。参考までにメモ。
cloc src 2934 text files. 2895 unique files. 74 files ignored. github.com/AlDanial/cloc v 1.88 T=4.39 s (660.1 files/s, 78773.3 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- TypeScript 2410 18435 2578 122610 JavaScript 118 23545 69642 81359 HTML 201 981 14 13184 Sass 153 1141 278 7228 JSON 5 0 0 3223 CSS 2 2 0 502 SVG 1 0 0 495 Markdown 5 63 0 212 ------------------------------------------------------------------------------- SUM: 2895 44167 72512 228813 -------------------------------------------------------------------------------
npm run start(ng serve)
AngularCLI | 1回目(ms) | 2回目(ms) | 3回目(ms) | 平均(ms) | totalsize |
---|---|---|---|---|---|
v10.0.5 | 46603 | 48155 | 45934 | 46897.33333 | 18.441MB |
npm run build(ng build --aot --crossOrigin=use-credentials)
AngularCLI | 1回目(ms) | 2回目(ms) | 3回目(ms) | 平均(ms) | totalsize |
---|---|---|---|---|---|
v10.0.5 | 68010 | 55808 | 49567 | 57795 | 41.0786MB |
npm run build(ng build --aot --crossOrigin=use-credentials --prod)
AngularCLI | 1回目(ms) | 2回目(ms) | 3回目(ms) | 平均(ms) | totalsize |
---|---|---|---|---|---|
v10.0.5 | 119982 | 62811 | 59576 | 80789.66667 | 11.85074MB |
週報という名の日記(2020/1/16)
今週の週報をかく。
体調と働き方の話
週明けは心も体も元気で長時間働いてしまいがち。夜行性なところがあるので、疲れるまでずっと仕事してしまったりする。日によって集中力にばらつきがあるから、集中しているときにがっとやってしまおうとするんだけど、これをやると週末に向けてだんだん疲れてしまう。バランス取らないとなー。仕事終わり、暇だなー、他のことやる気起きないし仕事するかーみたいな気持ちになったりして、仕事以外のことを蔑ろにしちゃう感じがちょっと健全じゃなかった気もする。気をつけよう。
木曜日は頭痛が酷くて気分も悪くて早めに退勤した。原因はなんだろう。頭痛の頻度がここ一年くらい頻繁になった気がする。しばらく我慢してそれでもひどい時は薬を飲むけど、さっさと飲んだ方が活動できて良いのかもしれない。薬に頼りすぎるのもな、という気持ちがあるので、何かしらlogをつけて原因を探してみるのもありかもしれない。最近ちょっと食事を減らしすぎたのかもというのと、生活習慣の乱れ、水分不足、睡眠不足、換気不足など心当たりがありすぎてよくわからん。ひとまず「頭痛ろぐ」というアプリを入れてみた。このアプリで記録をとりつつ、しばらく様子見てみる。
勉強会の話
水曜日にFront-End Study #3「『当たり前』をつくりだすWebアクセシビリティ」があった。フロントエンド領域に関する技術を網羅するフロントエンド勉強会シリーズということで、その1つとしてアクセシビリティが取り上げられていた。こういうのってあんまりなかったんじゃないかなという気がしており、アクセシビリティやっていこうっていう意識の広がりを感じた。参加者も1000人を超えていて、これを機会にアクセシビリティに興味を持った人も多いのではないかと思うので、とても良い企画だなぁと思った。
水曜日は、ng-japan OnAirもあって、アドベントカレンダー2020記事紹介がされてた。そこで自分が書いた記事も選ばれていてとってもとってもうれしかった。
社内でアクセシビリティ輪読会を企画していて来週からやるんだけど、アシストしてくれる方もいて神。
ほんと、周りからモチベーションを支えてもらいながら前進している感じがしている。ありがたい。
週末しっかり休んで来週も楽しく仕事していきたい。
週報という名の日記(2020/1/8)
金曜日は一週間を振り返ってメモを残しておくことにしたので書いている。
今週は年末年始休暇明けてまだ1週間と思えない感じだった。正月ボケとかもなかった。休みが短かったからかな。
生活改善
年始に色々目標を立てたんだけど、今仕事が忙しくてなかなかできていないこともあるが、テコ入れしていきたい。
腸活をしようと思って、ビオフェルミンS+を買ってみた。2ヶ月飲み続けてみることにした。食べ過ぎ説があるので、昼食の量も減らしてみた。ただ食事の固定化はすぐ飽きるので向いていない。ひとまず、食物繊維と発酵食品を意識して食べるようにはしてる。あとタンパク質。ただ、早寝早起きは相変わらず苦手。。まじ課題。遅く寝るか、終業後変なとこで寝落ちするかの二択状態...。
あと、自然音をBGMに流すのがとても良い。気に入った。 保冷・保温してくれるタンブラーも導入して、それもとってもお気に入り。いいかんじ。下半身が寒いので、無印のもこもこパンツも買った。まじ最高。寒くて集中できないってのがなくなった^^
TypeScript
ついさっきコードを書きながらTypeScript力の足りなさを感じて凹んだので、週末はTypeScript学習をやる。uhyoさんのこの記事のシリーズ?を読んで行こうかなと思う。
つよつよになるぞ。
アクセシビリティ輪読会
仕事で余裕がないこともあり、いつから始めるか、何をやるか迷っていたけど、Twitterで呟いたところ実例を教えていただいた。毎週30分時間をとって本を音読、予習などはなしってやり方をやってると教えていただき、とても参考になった。今、割とタイトなスケジュールの新規開発をやっているので結構余裕がなく、ちょっと迷うけど、超ライトに初めて行こうかなと思っているところ。
ちなみに読む本は「デザイニングWebアクセシビリティ」という本の予定。 デザイニングWebアクセシビリティ: アクセシブルな設計やコンテンツ制作のアプローチ | 太田良典, 伊原力也 | インターネット・Web開発 | Kindleストア | Amazon
モバイルみたいなUIをどう実現するかの検討
今toCアプリを作っており、Angularを使ってるんだけど、UIはモバイルみたいなスワイプ移動をイメージしてる部分があったりして、実装どうしようかなーってのを年末考えてた。 やりたいのは、
- ボトムシート
- カルーセル
- tabのスワイプ移動
とかがメイン。 ボトムシートならAngularMaterialにあるんだけど、他がなくてどうしよっかなーって思ってた。相談したらIonicが良いのではってアドバイスもらって見てみたけど、tabのUIコンポーネントにはswipeイベントはなさそうで自分ではやす必要がありそうだった。Slidesコンポーネントはあるが、これはSwiper.jsを使っているらしい。正直Ionicを全く使ったことない自分としては、まだ趣味で使ったことがあるAngularMaterialの方が使い勝手がわかっていて安心だった。結局、AngularMaterial + Swiper.jsを使うことにした。自分が実装する場合そちらの方が工数削減になると判断した。
新規開発に関して
toCアプリの大部分を一人で実装する予定で、要件検討とか調査と並行して実装しているのでまとまった時間が取れずになかなか進まなかったりする。やりたかったことなので楽しい反面、知見不足を感じたりもする。でもこういうのは積み重ねだし、知見不足は相談したりして解決している。ありがたみ。溜め込みすぎないように弱音吐きつつやっていきたい。 今はちょっと大変だなって思うこともあるけど、終わった後の成長を思うと楽しみ。
ほしいもの2021
ほしいものメモです。
iPad Air とApple Pencil(第2世代)
今年はいっぱいお絵描きする予定なのでほしい。というか、今日ポチった\\\٩( 'ω' )و ////
わー\\\٩( 'ω' )و ////
色はスペースグレイ、容量は256GBにした。届くのが楽しみ。
お絵描き用のシートも買ってみた。紙みたいな書き心地になるらしいので早く試してみたい。
Amazon | iPad Air/10.9 2020モデル ペーパーライク フィルム 紙のような描き心地 反射低減 アンチグレア 保護フィルム ペン先の磨耗低減仕様 「PCフィルター専門工房」 | PCフィルター専門工房 | タブレット用保護フィルム 通販
Herman Miller セイルチェア
自宅でリモートワークの際に座っている椅子、見た目はまぁかわいいのだが長時間座るのに全く適していない。なので椅子が欲しい。今気になってるのはセイルチェアなんだけど、見た目重視で言ってるだけなので座りに行ってみたい。白グレーの色味がかわいい。
Yogibo
だらだらしたい時とか読書の時に使いたい。去年店舗に座りに行ってみたけど、座り心地がめっちゃ良い最高。ある程度しっかりしているのも良い。種類はまだ決めてないけど、miniで良さそうな気はする。買うぞってタイミングでまた座りに行って決めたい。
昇降デスクとモニターアーム
欲を言えば昇降デスクとモニターアームも欲しい。でも優先順位は低めなので様子見。 メモってことで気になるやつのリンクを貼っておく。
Amazonベーシック モニターアーム シングル ディスプレイタイプ ブラック
エルゴトロン LX デスクマウント モニターアーム ホワイト 45-490-216
まとめ
ほしい気持ちをはきだすためのメモでした。お年玉ほしい。
2021年にやったこと
今日は2020/12/31なので、2021年にやりたいことを書いておく。やりたいことを過去形で書くと目標達成率が上がると聞いたことがあるし、実感したこともあるので「やったこと」として過去形で書いてみる。
1.生活を整える
運動
腹筋、背筋、スクワットをして体を引き締め、自分の体型が以前より好きになった。体力もついた。腹筋には薄ら縦線が入った。筋肉痛の日は無理せず休んだり、筋肉痛じゃない場所の筋トレをした。YouTubeのダイエット動画がモチベーション維持に役立った。 引っ越して急な坂の上の家に住むようになったので、駅やスーパーの行き来だけでだいぶ運動になった。今では息も上がらず平気で登れるようになったのでかなり体力ついたと思う。夏にハーフパンツをはけるようになって、好きな服を気にせず着られるようになったのも嬉しい。
引っ越し
以前より広くて静かで快適なところに引っ越した。前の家のストレスが全部なくなった。最高。東京を離れたので東京へ行くのはちょっと時間がかかるけど、仕事もほぼリモートなのでメリットの方が圧勝。
ちゃんと寝る
1日6〜8h寝ることは去年に引き続き継続できた。起きる時間を固定にすることを心がけ、毎日30分から1時間の朝活ができるようになった。朝活では主に英語の勉強をした。
歯列矯正を終わらせた
2019年から始めた歯列矯正、サボりまくって長引いていたけど、2021年にやっと終わらせられた!嬉しい!
2.仕事の話
メインの仕事
(メインの仕事のことはまだあまり詳しく書けないので、ぼんやり書く)
目の前の担当プロジェクトに対してベストを尽くした。界王拳で前倒しにすることを意識した。不安なことは早め早めに潰して行った。一人で抱え込まず、いっぱいいっぱいにならないように周りの方も頼った。頼らせてもらいつつも自分のベストは尽せたと思う。また一つ経験を経て視野が広がった。周りにもアサインしてもらえたことにも感謝。ユーザーからのフィードバックを色々と受けられ、改善して行けたことにもとてもやりがいを感じた。今年もとても充実した一年だった。仕事楽しい。
アクセシビリティの取り組み
デザイナーさんと輪読会を行った。なかなか読書時間が取れていなかったこともあり、一緒に読み進められる点はすごくありがたかった。
輪読会は以下を理想として取り組んだ。
- 本を読むきっかけの場
- デザイナーとエンジニアの知見交換の場(気をつけていること、気をつけて欲しいこと)
- やってみたいことを試す
- 外部勉強会の内容シェアとか
- 業務の負担にならない範囲で持ち回りでネタを話すなど
- アクセシビリティに詳しい方にお願いして質問会
私が輪読会の言い出しっぺではあるが、リードできるほど知識がなかったので、そこを何かしらで補いつつどうすれば意義のある輪読会になるか相談しながら進めた。仕事もみんないそがしかったので、準備が負担にならないやり方を模索した。これを機会に関わったことがなかったデザイナーさんとも関わることができ、知見交換もできた。とても有意義な輪読会になった。
3.自己投資
英語
以下に絞って英語学習をした。
- 中学英文法の復讐(音読しまくる、発音調べる)1ヶ月
- 瞬間英作文(音読しまくる、発音調べる)1ヶ月
- Youtubeの技術動画を聴けるようにする(ひとまず、a11yの短い動画を完璧に聴けるように)1ヶ月
ここまでやったところで、英会話を追加した。
- レアジョブ(週2回)
これにより、技術イベントの動画を聴きながら理解できるようになったし、英語のドキュメントも前よりスムーズに理解できるようになった。英会話では受け身だとなかなかみにならないため、質問を用意して挑むようにした。あんなに苦手意識があった英語を聴けるようになり、話せるようになり、ものすごく嬉しい。
アウトプット
アウトプットは月1くらいでやってきた。内容は日常の仕事の話を軽くブログにまとめる感じがメインだった。金曜日の夜に自分用週報的なのをまとめる感じで軽く書いておくと、一気にまとめるより楽で習慣にしやすくて良かった。
絵を描く
2021年はイラストをたくさん描いた。土曜日の夜に絵を描く時間を設け、週1は何かしらをインスタにアップした。ストックイラストとグッズ作成も定期的に行った。少しずつ売れるようになり、月1,000円程度の収入が安定して入ってくるようになった。額としては少ないかもしれないが、個人的には大きな進歩だった。これにより、イラストを描くことのハードルも下がり、描きたい絵を以前よりも描けるようになった。オンラインのイラストコースを受講したのもとても勉強になった。表現の幅が広がった。今後は動くイラストにチャレンジしていきたい。ゆくゆくはイラストを趣味兼副業にしていきたい。
読書する
あー漫画読みたいと思った時は、割と軽く読める技術書を手にとって読むようにした。自宅にソファーを導入したこともあり、読書が捗った。隙間時間を使った読書ってすごく良い。結果的に読書量が増えたように感じる。平均して月1冊は読めた。
まとめ
今年もかなり充実した一年となった。何年もずっと目標に掲げていた運動・英語・イラストに手応えのある進捗があったのがとても嬉しい。無理のない範囲で生活に取り込めた。来年も続けていきたい。
2020年の振り返り
今日は12/31なので、2020年の振り返りをまとめておく。 今年の目標はこちら。
1.生活を整える
断捨離
2月に引越しをしたので、割とものを減らせた。主に、洋服と本を減らしたけど、洋服はやっぱり好きみたい。たくさんは必要ないけど、買い足してしまう。本は、電子書籍への移行を試みたが、やっぱり紙が好きみたい。特に技術書だと紙で読みたいタイプ。
この辺りは一度減らしたり試したりすることで、断捨離できる部分とそうでない部分がわかったのでよかった。ちなみに、断捨離に関してはミニマリストのお片付けYouTubeとか見るとかなり捗る。断捨離ハイみたいになる。ものを減らすことが目的ではなく、自分の好きなことに、やりたいことに集中するための手段なので、目的を見失わないようにする必要はある。
運動
これはモチベーションのアップダウンが激しく、できたりできなかったり。習慣化できたとは言えないレベルだった。元々体力がないのに、以前にもまして運動不足なので来年は習慣にしたい。
引っ越し
2月末に引越しをしたので達成できた。ただ、2月ごろから新型コロナの影響でほぼリモート勤務となったため、会社の近くに引っ越すことで通勤面のメリットがあったかと言えばどうだろう。。
引っ越すことによって、大幅にものを減らせたこと自体はとてもよかったので引越しにおける収穫はそこだったと思う。あと、初めてオートロック付きのデザイナーズマンションに引っ越したので最初はうれしかったw
ただ、大道路沿いで窓を開けると空気は臭く、部屋が狭く(これは少ないもので暮らしたい + 通勤前提で探していたため)リモートには不向きで夜中もトラックのおとでうるさい、、とずっと家にいるには辛い環境なので長くは住めないなという感じである。
ちゃんと寝る
これは達成できたと思う。基本リモートになったことにより、毎日6〜8時間寝られていたと思う。自分は元々ショートスリーパーじゃなく、どちらかと言えばロングスリーパーだと思うが、なかなか規則正しく睡眠を取ることが苦手だった。
基本リモートになってからは、何時間寝ると調子が良いかわかってきた気がする。8hくらい寝るとすっきりして起きられる。ショートスリーパーいいなぁ...笑
2.自己投資
英語
最初やる気満々でキク英文法を1ヶ月くらい毎日やってた時期があったが、途中で勉強方法に迷いが生じてからはモチベーションが下がってやめてしまった。世の中にはたくさんの英語勉強法があるので、どれかを信じて浮気しないでがっとやったほうが良いのだろうと思う。今度また再開する時はひとまずそのやり方でやり抜くようにしたい。
アウトプット
社内で3回オンラインイベントで2回LTをした。Zennに2件記事を投稿した。このぷにぷに日記は前半はちょいちょい何か書いているが、後半はほとんど書いてなかった。今年は社外でLTをしたので、自分的にはだいぶ成長だった。しかも2回もするとは思わなかった。背中を押してくれた方や機会をくださった方に感謝。
絵を描く
たまに絵を描いてインスタやTwitterにアップした。インスタにはイラストアカウントがあるが、ずっと更新しておらず、1年ぶりくらいに更新した。同僚の方でめちゃくちゃイラストうまい方がいて、その方が頻繁にイラストを上げていることも刺激になって再開した。
インスタで以前の同僚の方からリアクションもらえ、イラストが癒されると言ってもらえたこともすごくうれしかった。来年はもっと頻繁に描いていきたい。
読書する
感想を書いていた時期もあったが、だんだん書かなくなった。途中会社の同僚の方の呼びかけで始まった朝読書に参加したが、朝が苦手すぎたり仕事で余裕が無くなったりしてほとんど参加できなくなってきた。継続ってほんと難しい。継続できる人ほんとすごい。
まとめ
8つたてた目標のうち、断捨離・引越し・ちゃんと寝る・アウトプットは割とできたのではないかと思う(自分比)。他はたまにやったけど、継続・習慣と言えるほどではなかった。コロナとか色々あるけど、自分の目標とやったことに焦点を当てると、前進していることを感じられる良い1年だった。来年の目標はまた別で書くよ。
【DDD本読書メモ】ドメイン駆動設計とは
最近「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」という本を読んでいます。2週目です。
1週目は1人で黙々と読んでいたのですが、理解が不十分だと感じていました。読み返してより理解を深めたいと思っていたところ、社内で輪読会をする話が出たので参加し、2週目を読み進めています。
せっかくなので、理解を深めるために自分なりのまとめをブログに書いておこうと思います。これは自分の理解を深めること、自分がさっと見返すことを目的としています。 より正確な解釈や詳しい話は上記の本を読んでいただければと思います。
また、認識違いがあった場合はご教示いただければ幸いです。
ドメイン駆動設計とは
この記事ではCapter1の「ドメイン駆動設計とは」を読んだまとめを書いています。
ドメインとは
ドメインは「領域」という意味を持った言葉です。ソフトウェア開発におけるドメインは、「プログラムを適用する対象となる領域」のことです。
例えば会計システムの場合、金銭や帳票といった概念が登場します。これらは会計システムのドメインに含まれます。物流システムだと貨物や倉庫、運送手段などの概念が存在し、それらは物流システムのドメインに含まれます。そういった関心事が「ドメイン」に該当します。問題領域、業務領域と捉えるとわかりやすいかもしれません。
ドメイン駆動設計とは
ドメイン駆動設計とは「ドメインの知識に焦点を当てた設計手法」のことです。
「ドメインの知識に焦点を当てる」とはドメインに向き合い、その概念・事象をしっかり理解した上で、問題や問題解決に必要なことを導き出し、それをシステムに反映させることです。
「当たり前では?」と思いますが、当たり前のことを実践することは意外に難しかったりします。「作ったものがユーザーが求めるものではなかった...」というようなことは実際に起こり得ます。
そうした悲劇を生まないための道標としてドメイン駆動設計は有効な手段となります。
ドメインモデルとは
現実世界の複雑なドメインの概念から全てをソフトウェアに持ち込む必要はありません。ソフトウェアではソフトウェアが担う責務に必要な情報を抽出して扱うべきです。こうした抽象化する作業を「モデリング」、抽象化された概念を「モデル」と呼びます。ドメイン駆動設計では、ドメインの概念をモデリングして得られたモデルを「ドメインモデル」と呼びます。
モデリング - 現実の事象・概念を抽象化する作業 モデル - 現実の事象あるいは概念を抽象化した概念 ドメインモデル - ドメインの概念をモデリングして得られたモデル
ドメインオブジェクトとは
ドメインオブジェクトとは、ドメインモデルをソフトウェアで動作するモジュールとして表現したものです。
ドメインモデルは概念を抽象化した知識にとどまります。開発者はドメインモデルから真に問題解決に必要なものを選択し、ドメインオブジェクトとして実装します。
ドメインの概念 <=> ドメインモデル <=> ドメインオブジェクト
ドメインの概念に変化があれば、まずドメインモデルに反映させ、必要に応じてドメインオブジェクトを変更します。また、プログラムは曖昧な表現を受け入れられないため、ドメインオブジェクトを実装する過程でドメインの捉え方の見直しに繋がることもあります。
こうしてドメインの概念とドメインオブジェクトはドメインモデルを媒介に繋がり、お互いに影響し合う反復的な開発が実現されます。
ドメイン駆動設計のパターン
Capter1の終わりには、この本で学ぶドメイン駆動設計のパターンが挙げられていました。こうして俯瞰して見ると理解もしやすく助かります。見返したいのでメモしておきます。
- 知識を表現するパターン
- 値オブジェクト
- エンティティ
- ドメインサービス
- アプリケーションを実現するためのパターン
- リポジトリ
- アプリケーションサービス
- ファクトリ
- 知識を表現する、より発展的なパターン
- 集約
- 仕様
感想
「ドメイン駆動設計」を説明するだけでもいくつかワードが出てきました。1つ1つわかりやすく解説されており、理解しやすかったです。
また、これまで、DDDのメリットといえば
- ドメインの変更をプログラムに反映させやすいこと
- プログラムがドキュメントになること
などと捉えていましたが、「ドメインに向き合い、その概念・事象をしっかり理解した上で、問題や問題解決に必要なことを導き出し、それをシステムに反映させる」 という当たり前なことを当たり前にやるための補助
という認識は薄かったような気がしたので、改めて意義を確認できてよかったです。