ドメイン層に最適なアーキテクチャを考える:保守性・拡張性に優れたシステムを作る(8)(2/4 ページ)
前回「階層アーキテクチャの利点は複雑さの減少」は階層化アーキテクチャの考え方について説明してきました。今回は、階層化アーキテクチャにおけるサービス層と、設計が難しいとされるドメイン層についてどのように考えるのかを見ていきます。まず、最初に各層を設計するときに、拡張性・保守性を高めるために何を検討すべきかを考えてみましょう。
サービス層が持つべき機能とは
次にドメイン層について考えて見ます。サービス層は、業務サービスを実現する層です。サービス層はドメイン層に存在するビジネスロジックを利用してサービスを実現するためのサービスプロセスを実現しています。
そして、トランザクションの制御、セキュリティなどのシステム機能を実現します。
このとき業務機能(機能要件)とシステム機能(非機能要件)を実現する実装は、分離できるようにします。一般的にはEJBやAOPなどのフレームワークを利用し、ビジネスロジックにシステム機能が混在しないようにします。
ドメイン層の設計をどのように考えるか
ドメイン層は、ビジネスロジックを実装します。ビジネスロジックは、必要とするデータとともにエンティティクラスにカプセル化されます。これは、オブジェクト指向分析で作成された概念モデルを基に作成します。各エンティティクラスは、継承、インターフェイス、関連などを利用したクラス構造を持っています。
このように、ドメイン層では概念モデルで作成されたクラス構造が、そのままエンティティクラスで構成されることが望ましいことです。しかし、プログラム言語やデータベースの種類、性能などによる制約により、概念モデルがそのまま実装できない場合があります。
また、ドメイン層はビジネスロジックだけをPOJO(Plain Old Java Object)で実装できると大変わかりやすいです。システム的な機能である永続化などの実装は、ドメイン層では意識したくありません。あくまでもエンティティクラスに持つデータを参照・更新します。テーブルのデータを参照・更新することなど、テーブル操作に関することは一切知りたくありません。永続化は、エンティティクラスが保持しているデータが更新されたら、テーブル上の該当するデータと自動的に同期が取れるようになるのが理想です(この同期はパーシステンス層の役割になります)。
このように、理想的なドメイン層の設計は、次のように考えられます。
- 概念モデルでのクラス構造をそのまま実装できる
- ドメインロジックが永続化の機能を意識せず、POJOとしてエンティティクラスを実現できる
それでは、ドメイン層をどのように設計していけばよいのでしょうか。PofEAAにおけるドメイン層を実現するためのアーキテクチャパターンは次の3種類があります。
(A)Transaction Script
(B)Domain Model
(C)Table Module
それでは、この3つのパターンについて見ていきましょう。
Copyright © ITmedia, Inc. All Rights Reserved.