DDDの適用と、オニオンアーキテクチャの採用による解決
これらの問題を改善するために、まずロジックを細かく分解し、凝集度を上げるアプローチを試みた。しかし、その結果、依存関係が複雑化し、どのロジックがどこから呼ばれているのかが不明確になることが増えた。これにより、ユースケースの一部を変更する際にどこを修正すべきかが分からなくなる問題が発生した。最終的に、どのアーキテクチャでも、変更箇所とその影響範囲が明確であれば問題は解決すると結論付けた。そして、ロジック層にはアプリケーションロジックとドメインロジックの2種類が存在するという理解に至った。畠中氏は「これはDDDの書籍などでも言及されていて、実際に達成すべき重要な課題だと感じました」と振り返る。
アプリケーションロジックは仕様に基づいたもので、例えばメディカルフォースではこういうロジックがあるが、競合のプロダクトでは異なるといったものが該当する。アプリケーションロジックは、仕様に基づいて変更が容易にできる。一方、ドメインロジックは知識として蓄積され、メディカルフォースでも競合のプロダクトでも共通となる要素が含まれる。この2つを明確に分けることを意識した。
例えば、在庫アラートのケースでは、アラート通知というドメインロジックを用意しこちらに実際の処理を書いておく。それをアプリケーションロジックである在庫使用ロジックが呼び出す形にした。このようにすることで、高凝集・低結合を実現できる。また、アプリケーションロジックからはアプリケーションロジックを呼び出さず、ドメインロジックからはドメインロジックを呼び出さないというルールを守ることで、結合度を低くしながら高凝集を保った。カルテの名寄せ処理においても、患者の名寄せ処理をドメインロジックとし、アプリケーションロジックから呼び出すことでより効率的に管理できる。
畠中氏は、仕様変更だけでなく、改善活動についても話した。当初、フレームワークやORマッパーの変更は滅多にないと想定していたが、同社が活用するNode.jsの領域では、ORマッパーのデファクトスタンダードが変わってきていたり、発展したフレームワークも登場したりしている。フレームワークに依存しない設計方針をとっていたが、より変化に耐えられるように方針を転換した。また、データアクセス層については、エンティティの永続化と復元だけを担当させることを重視し、インフラストラクチャー層を設け、DBやORマッパーに対する処理を外側に配置した。
このように、高凝集・低結のためにさまざまなルールを設定したが、メンバーに周知徹底するのが難しいため最終的にオニオンアーキテクチャを採用した。ドメインモデルが中心にあり、ドメインサービス層、アプリケーションサービス層がアプリケーションの核となり、その周りさらにユーザーインタフェースやインフラストラクチャー、テストがある。
畠中氏はその効果について「結果として、仕様変更やテストがかなり楽になりました。当初は新規実装の速度が少し遅くなるのではないかと懸念していましたが、長期的に見ると、コードの再利用性が高まり、開発スピードも向上しています。これが非常に良かったと思っています。この経験を踏まえて、DDDやオニオンアーキテクチャについて考えていただけると幸いです」と語った。
