しなやか設計とは

DDDには『しなやかな設計』という概念があります。

今日は、どのような設計がしなやかか、というお話。

まず、ソフトウェアの最終的な目的ってなんでしょう?

それはユーザの役に立つことです。

必ずどこかに問題を解決したいと思っている人がいて、 その課題を解決するためにソフトウェアを利用します。

そして、ユーザの役に立ち続けるにはそのソフトウェアの開発者が既存のソースコードリファクタリングしたり、 要素を増やしたり結びつける必要が必ず出てきますよね。

なので、ユーザの役に立つためにはまずは開発者の役に立つものであることが求められています。

しなやかな設計でない状態では以下のようなことが起きます

- 設計要素が一枚岩になっていて重複する
- 1つ変更したら意図しないところも変わっちゃった
- 改修で「どれくらい他に影響あるかコードを調査します」
- クライアント開発者がモデルを理解するのに時間がかかる

こんな状態では、少しコードを触るだけでも常に不安がつきまとってしまいます。

開発者が楽しく仕事ができて、変更を呼び込むような設計こそ、しなやかな設計なんです。

あんまり日常生活でしなやかというワードを使わないので私のボキャブラリで言い換えると 『ナイスな設計』『イケてる設計』『いい感じの設計』みたいなイメージでしょうか!笑

具体的にどのような設計をしていくとしなやかになるのか、次に書いていこうと思います。

参考

https://www.amazon.co.jp/%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%82%A8%E3%83%B4%E3%82%A1%E3%83%B3%E3%82%B9%E3%81%AE%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88-Architects%E2%80%99Archive-%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%AE%9F%E8%B7%B5-%E3%82%A8%E3%83%AA%E3%83%83%E3%82%AF%E3%83%BB%E3%82%A8%E3%83%B4%E3%82%A1%E3%83%B3%E3%82%B9/dp/4798121967