texta.fm #1 まとめ

Thu, 01 Oct 2020 09:00:00 +0900

texta.fm

texta.fm #1（2020年8月27日放送分）を聞いて、特にDDDについて学びが多かったのでまとめました。

エヴァンス本を読む前に知っておいた方がいい時代背景、そして、意識すべき点を知ることができるので、
時間があればぜひ実際に聞きに行ってみてください。

話者：

以降、勉強になった点を抜き出していきます。
なお、<>内に記載している時間は、記述内容が実際に話されている時間を示しています。

<6分30秒ぐらいから>

エリック・エヴァンスがDDDで解決しようとしていた問題は以下の2点

<9分45秒ぐらいから>

2000年代前半はフェーズで区切ったソフトウェア開発が主流だった。
そして、その区切られたフェーズのひとつである「モデリングフェーズ」では、
分析や設計を通してモデルを作り上げていくのであるが、
開発の対象領域をきちんと写し取った抽象的なモデル（分析モデル）を作ることが最大の目的であった。

しかし、開発フェーズに入った時、分析モデルでは不完全なことが多かった。
よって、開発で使えるように修正が加えられ、最終的には分析モデルとは全く異なるモデルができあがる。

コードを書かないと分からないこと、実際にシステムが使われ始めないと分からないことがたくさんあるので、当然の結果である。

<17分20秒ぐらいから>

分析モデルとコード間の乖離を解決するために、
分析モデル→開発時のモデルの一方通行ではなく、
開発時のモデル↔分析モデルのように両方向にフィードバックする。
そして、フィードバックをもとに改善のループを回していくことが重要。
（＝アジャイルソフトウェア開発時代の改善ループの回し方）

<25分00秒ぐらいから>

現在ではあまり分析モデルとコード間の乖離が問題にならない。
理由としては、分析モデルの作成フェーズ（モデリングフェーズ）と開発フェーズを担当する人が同じになってきたから。

昨今の開発ではこうした開発体制が普通になっているので、
そもそも今いる大半のエンジニアにはイメージがつきにくい事象である。

したがって、現在は、DDDと言われるとビジネス側と開発側の乖離に注目が行きがち。

<21分40秒ぐらいから>

コードとドメイン知識間の乖離を無くし、
一致させ続ける反復的作業こそが大事であると訴えたことがとても良かった。

つまり、先述したとおり、
フィードバックが 分析モデル→開発時のモデルの一方通行 だったものを
開発時のモデル↔分析モデルのような両方向 にしようと提唱したことこそが最重要。

ここを意識して学ぼう！

<33分00秒ぐらいから>

デザインパターンの部分（2部、3部あたり）はもちろん大事であるが、
エヴァンス本の本質的な部分ではない。