3つのエンタープライズアプリケーションアーキテクチャーパターン
3つのエンタープライズアプリケーションアーキテクチャーパターン
最近、エンタープライズアプリケーションアーキテクチャーパターンという本を通して、3つのアーキテクチャパターンを学びました。自分の頭の中を整理するということも兼ねて、まとめてみようと思います。
3つのアーキテクチャパターンとは
この本では、以下の3つのアーキテクチャパターンが紹介されました。
トランザクションスクリプトとは
一連の手続きとしてロジックをまとめていく手法で、ユースケース毎に一つのロジックを形成していくことが多いです。同じようなユースケースが生じたときに同様なロジックが複数のサービスクラスに散財してしまいます。大規模なシステムになればなるほど、同様なロジックが複数箇所に散財する可能性が高くなるため、今後拡張する可能性が高いシステムには使用しない方が良いと思いました。
ドメインモデルとは
それぞれのドメイン毎に明確に、担当するプロパティと振る舞いの責務を設け、それらのドメインが協働することによって、ロジックを形成していく手法のことです。ドメインが協働することでロジックを形成するため、同様なロジックが必要なユースケースが生じたときにも、そのロジックを責務にもつドメイン群を呼び出すだけなので、複数箇所にロジックが散財する可能性は低いです。ただし、ドメイン毎に明確に責務を設けて、それらのドメインの協働によってロジックを形成する手法なので、作成するクラスや振る舞いの量が多くなり、開発当初からコード量が多くなるので、小規模のシステム開発には適さないと思いました。
テーブルモジュールとは
上記二つのパターンの中間に位置するパターンです。DBのレコードに合わせて、ドメインを形成し、ロジックもドメイン毎に定義されます。DBレコードに合わせることから、一つ一つのドメインが大きくなり、システムの規模が大きくなるにつれて、責務の範囲が大きくなることが短所と言えます。責務の範囲が大きくなると、コードの見通しが悪くなったり、同様な責務を持ったクラスを定義してしまう可能性が高まり、コードの品質を低下される原因になります。
どのように使い分けるか
僕はシステムの拡張する可能性が少ないシステムの場合は、トランザクションスクリプトを使用し、システムを拡張する可能性が高い場合には、ドメインモデルを選択すると思います。
なんだかんだ、ユースケース処理毎にロジックがまとまっていたら、コードの見通しが良いです。最初からそれほど拡張する可能性がない社内システムなどでは、たとえ重複コードを作成してしまったとしても、それほどコードの見通しが悪くなることはないと思います。
ただし、システムが拡張する可能性が大きいシステムについては、状況が異なります。一度、ロジックが散財しだすと、システムの拡張に合わせて、その他のロジックの散財を生み出します。そのような状態で、システムのロジックを変更することになると、修正すべきロジックの対象範囲がすごく大きくなってしまいます。このようなことにならないために、ドメインモデルを採用し、ロジックが一箇所になるようにするのが良いと思います。
