バックエンドをCleanにしておく話

Clean Architectureの思想で作ったバックエンドで何ができるのかを書きたい

メリット：

• 変更容易性

デメリット：

• コードを書く量が増えて面倒
• 実装する上である程度の経験が求められる

メリット詳細：
何はともあれ変更容易性。実装する上でハード（変更し辛い）と思っている部分があればソフト（変更し易い）に置き換えられる。作りきりのソフトウェアではそのコストを掛ける旨味は薄い。Webアプリのような出して終わりではなく、日々のユーザーの反応や事業の変化に合わせて形を変えていくソフトウェアの方が恩恵を得られる。

デメリット詳細：
各レイヤーを分割することでコードを書く量が増える。一つはDIのためのコードで、レイヤーが分かれるほど、かつ各レイヤーのコンポーネントが多いほど書く量が増える。もう一つは各レイヤーをまたぐ際のデータの変換で、特に外部とのやり取りを担うレイヤー（Httpインターフェイス、Repository）で発生する。

実装する上である程度の経験が求められるのは、特にEntityのレイヤーを実装する時に懸念している。いままでの経験でEntityはDBのテーブル構成とイコールになるように作るアプリケーションが多かったのもあり、多くの人がそれに慣れ親しんでいるという認識を持っている。ただしこのことがソフトウェアをハードにしており、Cleanに作るために脱却しなければいけないものだと思っている。ではどのようにEntityを実装すれば良いのか？DDDっぽくやるのであれば着実に進められそうだが、そうでないならやはり経験が求められそう。

ここまで書いて思ったけどサンプルコード無いと大変伝えづらいな