DDD, “クリーンアーキテクチャ”というアーキテクチャを採用することが一般的には望ましいとされている。それは、これらのアーキテクチャがソフトウェアで最も重要なビジネスロジックの変更が簡単になるからだとされている。ソフトウェアを作る上では、サービスとしてユーザに提供するビジネスロジック、あるいはその組み合わせであるユースケースとは別にデータベース、ロギング、採用するフレームワーク (FW) など考慮すべきことが多岐に渡る。上記のアーキテクチャは最も重要なビジネスロジックをその他の考えるべきことと分け、ビジネスロジックの実装を優先すること、ビジネスロジックの変更容易性を高めることを目的としている。だから、何のデータベースを採用するか、などのことはビジネスロジックに比べると重要度は低いので、その意思決定をできるだけ延期させる。この意思決定の延期がこれらのアーキテクチャの本質であると考える。しかし、この前提が正しいとすると、FWを一度選択すればこれらことはFWによって決められるのでそもそも意思決定する必要がない。そもそも「FWの決定を延期することができる」とあるが、それは本当に可能なのだろうか。データベースなどについて技術選定を行なう際、その選定基準が明確になっていないと意思決定は遅くなってしまう。選定基準がある程度明確になっていて、その上で選定に悩んでいるという状況であれば、意思決定を延期させることに意味があると思うが、選定基準が明確でない、あるいは基準がないような状況であれば、この意思決定には時間がかかり時間の無駄なので時間を割くべきではないと考える。以上のことから、必要なあらゆることがらについて選定基準が明確でないのであれば、FWをツールとして利用する (FWに依存しない)のではなく、FWにどっぷり依存してしまった方がいいのではないと考える。そうすることによってソフトウェアの最も重要なサービスをユーザにいち早く提供できるからである。

前述のアーキテクチャについて、もう一つ重要な観点は変更容易性である。 FWや外部のモジュールは自サービスから見ると依存の対象である。それが将来使えなくなってしまったり、他のものを利用することを決定したときに、ソフトウェアがこれらに強く依存しているとそれを引きはがす作業が必要となる。そこで、これらのアーキテクチャではこれら外部要因に依存しないように設計することによって、これらを交換することが簡単になるとされている。しかし、私は将来この交換がどの程度の確率で発生しえるものなのかが気になる。自分はエンジニア経験が浅いので、このような交換を経験したことがない。もし、将来にその交換が必要になる可能性がある程度高いのであれば、この変更容易性について考慮しなければならないが、それが限りなく0に近いのであれば考える必要はないのではないか？ (ここで言う変更容易性はアプリケーション内部のものとは違って外部要因のものを指す) この観点からも、将来変更する可能性が0に近いのであればFWなどの外部要因に依存してしまった方がユーザへのサービスのデリバリーという観点では良いのではないか？それは、ソフトウェアはローンチしてお金になるから意味があるのであって、そうなる前に時間をかけてしまって結局お金にならなければ膨大な機会損失になると考えるからである。

私は前述のアーキテクチャが述べようとしているのは、ビジネスロジックを他と切りはなすのみに留まらず、コード単位のsolid原則を外部要因に拡張したものだと考えている。それが必要であるならば採用すべきだと思うし、必要でないならば採用する必要はないと思う。

ビジネスロジックを他と切りはなす,についてはその通りであると思うが、これはこれらのアーキテクチャの新しい考え方ではない。それ以前から存在するMVCもその考えに沿っているはずだ。 MVCにおいてよく問題となるのは、fat controllerだが、これはビジネスロジックがその他の関心ごとに染み出してしまっているのが問題だ。ビジネスロジックはmodelにまとめてしまえば問題ないと思う。

アーキテクチャで考えたこと