はじめに
この度、基幹システムの移行プロジェクトにて、従来の開発手法とは異なる手順で開発を行いました。
本稼働後に判明した追加要件のため、既存のデータベース（DB）やユーザーインターフェース（UI）をそのまま利用することが決まったのです。その結果として、新規開発領域は“複雑な業務ロジックだけ”に限定されました。
基幹システムにおける“複雑な業務ロジック”
ここで言う基幹システムの“複雑な業務ロジック”とは、商流の制約や現場のノウハウなど、業務ルールに対応するための、計算・判定・条件分岐などの処理を指します。
これらの“複雑な業務ロジック”の開発では、将来的な要件の追加に対応が必須です。
そのため、うわさに聞くユニットテストとクラスライブラリの組み合わせで開発をスタートしました。
偶然の制約がもたらしたもの
当初、この慣れない開発に「やりにくいな」と感じたのが正直なところです。
しかし、実際に手を動かし開発を進めていくうちに、この“制約”が、思いがけない効果を与えてくれたことに気づきました。UIやDBといった「周辺の要素」に意識が分散することなく、業務ロジックをクラスライブラリとユニットテストによって集中的に構築できました。
業務知識の整理と設計への集中
UIの見た目やDBのスキーマ設計といった制約から離れて、純粋にビジネスの言葉をコードに表現し、業務知識をいかに整理するかに集中することができました。
ユニットテストによる安心のリファクタリング
業務ルールの正しさをユニットテストで厳密にチェックできたことは、コードの内部構造を整理するリファクタリングを安心して進めることができました。テストが強力なセーフティネットとして機能し、変更に対する不安を大幅に軽減してくれました。
責務分離と値オブジェクト化の重要性の実感
業務ロジックに深く向き合う過程で、一つのクラスに多くの役割を担わせない責務分離の原則、そして特定の意味を持つデータを独立した型として扱う値オブジェクトの有効性を、実装とテストを通じて体感的に理解することができました。
業務ロジックに集中する開発体験
出来上がったコードは、見通しが良く変更も容易で、予想以上に快適な開発体験となりました。
この“偶然得た体験”を他の開発にも活かしたいと思い、言語化に挑戦しました。
まずGitのログを振り返り、変更内容を整理。
さらに、実施した内容を抽象化し、一般的な手法に当てはまるかAIにも相談しながらまとめていきました。
すると驚くべきことに、増田亨さんが解説していたドメイン駆動設計（DDD）の内容とすべてが一致していました。
どうやら私は意図せず、DDDの本質的な開発体験を“偶然”得ていたのです。
実はこれこそがDDDの本質！？
この一連の開発経験を通じて、「DDDは難解な設計手法である」という従来の認識を改めることになりました。むしろそれは、業務知識を「型」と「テスト」によって表現し、ビジネスの変化に合わせて継続的に育成していく、極めて実践的なアプローチなのだと気づいたのです。
UIやDBといったシステムの「飾り」がない分、業務ロジックの設計、テスト、そしてリファクタリングという“本質”に深く没頭できました。これにより、いかにして変化に強く、保守性の高いシステムを構築するかというDDDの核心を、座学としてではなく、身体で覚えることができたように感じています。
今後は、有効だと感じた手法について、個別に掘り下げて整理したいと考えています。
7/27追記：第二弾の記事はこちら。状況説明をもう少し詳しく書いたものです
なぜ複雑な業務ロジックの実装をスムーズに開発できたのか：基幹システム移行でTDD/DDDを実践した理由
https://qiita.com/panda728z/items/191080b59e03a45d75b1
7/30追記：第三弾の記事はこちら。第二弾で触れた可読性をテーマにしています
基幹システム移行で得た「読みやすいコード」：DDDが変えた可読性の常識
https://qiita.com/panda728z/items/5982bbb10e5f9098b608