全3回に渡って、ここ数年担当している小規模レガシープロジェクトで、何処を目指して、どうゆう方針で改善を行なっているかを纏めてみました。このブログにとっては多くの方に読んでいただけたようで嬉しいです。

• ドメインを純粋に保つ (レガシープロジェクトの改善活動について)

前回が完結編だったのですが、追加で、「何を避けたか」という観点を説明してみたいと思います。避けた事を説明することで、継続的な改善を行なう上での方針がよりはっきりするのではないかと考えたためです。あとがきとして「何を避けたか」を書いてみます。

何を避けたか

(ヘキサゴナル|オニオン|クリーン)アーキテクチャありきの構成変更

レガシープロジェクトは、十分なテストも無く、ソースコードを読むのが難しく、修正も難しくなってきているものです。システムのリプレイスをするという決断をしたのでなければ、これらのアーキテクチャありきの構成変更は危険度が高いです。また、理想的な状態が明確になっていない人が、継続的に機能追加を繰替えしていくと、層だけが分かれた分カオス度が増してしまうこともありそうです。

「ドメインを純粋に保つ」の説明では、純粋なビジネス概念の隔離場所としてのドメインを作成しているので、部分的に上記のアーキテクチャの考え方を参考にしていますが、アーキテクチャありきでの構成変更ではないという意図です。

Webフレームワークの便利機能を使わないようにする

Webフレームワークの便利機能は、時にレガシープロジェクトのアプリケーションコードを更にカオスにすることに貢献してしまうようなものもあります。(例えばORMで簡単にデータベースアクセス可能なためビジネスロジックと絡まってしまう等)

対策として、直接便利機能を使うことを禁止してしまうという決定をしてしまいがちです。しかし、レガシープロジェクトのアプリケーションは元々便利機能を使いまくっているので、「ドメインを純粋に保つ」の説明では注意深くビジネス概念を抽出することに専念することで、Webフレームワークの便利機能はできるだけそのまま使うという方針にしました。

初手でのドメインエンティティの作成

サンプルプロジェクトとして用意した仮想Issue管理システムで、ドメイン・モデリングを進めようとすると、まず Issueというエンティティをドメインに入れたくなってしまうと思います。しかし既存のレガシープロジェクトのソースコード上では、プログラマはデータベースから取得した1行のレコードに対応するORMのオブジェクトを課題(Issue)と認識しています。この状態でドメインにIssueクラスを作ると、正しく使い分けるのが難しくなるので、初手ではIssueをドメインに入れるのを避けました。

トランザクションスクリプトをそのままドメインに入れる

トランザクションスクリプト的なビジネスロジック(DBから読んで、○○だったら××変換処理して、DBに保存するみたいな)ものは、純粋なビジネス概念ではないと判断しドメインには含めないようにしました。これをドメインに入れようとすると、リポジトリパターンを使って依存関係を逆転する必要が出てきて複雑化するのを避けるためです。「ドメインを純粋に保つ」の考え方では、上の例は「○○だったら」という条件判断のビジネス概念と「××変換処理」というビジネス概念に適切な名前を付けて抽出しドメインに隔離することになります。

まとめ

担当しているレガシープロジェクトで「ドメインを純粋に保つ」をスローガンに進めている改善は、上手く行っていると感じています。とは言え、レガシープロジェクトのレガシー部分はまだまだ大量に存在しているため、日々改善を継続していくつもりです。

あとがきまで読んでいただきありがとうございます。フィードバック等いただけると嬉しいです。

続編を書きました。

ドメインを純粋に保つ (レガシープロジェクトの改善活動について) (5) CSVダウンロード機能

ドメインを純粋に保つインデックス

シリーズ化してますので、他記事もご覧ください。

• ドメインを純粋に保つ