書籍 #

増田亨,現場で使えるシステム設計の原則,技術評論社
成瀬允宣,ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本,翔泳社

アーキテクチャ考える以前に、やるべきことをやっていないのでは？という疑問がきっかけ #

SwiftUIでアプリを開発していると、UIKit時代と異なり Presenter でもないし ViewModel でもない、なんともいえないオブジェクトができてしまうようになりました。 SwiftUI自体がデータバインディングの機構を持っているし、単一方向のデータフローを持っているので、それらが最適ではないとネットでもよく言われています。それでも ViewModel とか UseCase（ここではView寄りで状態管理も含んだもの）といった名前でその設計を持ち込むと、今度は、SwiftUI の State や EnvironmentObject を十分に活用できない非効率な設計になってしまいました。

そうするうちに、ビジネスロジックの複製が発生するようになりました。これには複合的な要因がありますが、システムへの理解（ひいてはドメインへの理解）が不十分なまま、まずは動かして検証するといったことをしているうちに、大きなロジックのコピーが３箇所４箇所と増えていきました。 SwiftUIとビジネスロジックの接続をどうするか悩んでいるうちに、ビジネスロジックが肥大化してしまったということです。これでは、UI側のアーキテクチャにTCAが良いのかどうか、などを考えている場合ではありません。

そもそも、アーキテクチャをどうするか考える以前に、やるべきことをやっていないのでは？ という感覚を持ち始めました。ビジネスロジック側の設計を改善する必要を感じました。そこで手に取ったのが「現場で使えるシステム設計の原則」と「ドメイン駆動設計入門」でした。

そして、「現場で使えるシステム設計の原則」と「ドメイン駆動設計入門」を手にとる #

ビジネスロジックの設計を改善する必要性を感じてシステムアーキテクチャに関する書籍を探していたところ、「現場で使えるシステム設計の原則」を発見しました。内容がドメイン駆動設計に触れている書籍であることは、各種サイトのレビューからもわかっていました。しかし、タイトルにドメイン駆動設計が入っていないところは選びやすいポイントでした。ドメイン駆動設計を学ぶ本というよりは、システム設計を良くするヒントを得る目的で選びました。この本を選んで正解でした。

「現場で使える〜」を読み終えた後、よりドメイン駆動設計について知りたいと感じ「ドメイン駆動設計入門」を手に取りました。難しそうな印象がありましたが、Amazonの「これを買った人はこちらも買っています」のレコメンド欄に表示されたので、勉強ということで購入しました。予想に反してこちらの本も大変読みやすく、たくさんの事例をもってドメイン駆動設計を解説してありました。全体の概要をつかみ、発展的な書籍へ踏み込む足がかりとなる感じがありました。

なお、3年前に購入した「エリック・エヴァンスのドメイン駆動設計」は、iPadの中で埃をかぶっています。（なお最近は、紙の書籍を購入して読むようにしています）

2冊を読み終えて、実装や設計に生じた変化 #

今回の２冊を手元に置いた状態で、複雑になってしまったアプリの実装を、少しずつ改善しています。

まず、値オブジェクト・エンティティの導入から始めました。ビジネスロジックの中で条件分岐などの判断/加工/計算をしている箇所を探して、それがドメインの重要な知識だと感じたら、ドメインオブジェクトを作って、知識を移動するようにしました。 Swiftでは、struct（値型）とclass（参照型）のクラスを作ることができます。また、let（不変の変数を定義する接頭辞）があるので、これらを組み合わせることで、ドメインオブジェクトをスムーズに導入していけます。

次に、ビジネスロジックの中でも、処理の流れや意図を読み取りにくくするような処理や意味のある処理のまとまりをServiceに移動したり、永続化周りの処理をRepositoryに切り出したりしていきました。これまでServiceという名前にいまいちイメージがピンときていなかったのですが、「ドメイン駆動設計入門」を読んだことで、積極的にServiceに処理を委譲できるようになりました。しばしば「Helper」クラスの乱立や肥大化を経験してきましたが、Helperクラスが不要になるほど、意味のある実装をもったServiceに便利さを感じます。

それと並行して、開発チーム内で使用している言葉や、アプリの処理を説明する際に使用している言葉を内省しました。現段階では、少しずつ、チームの言葉とプログラムの言葉を揃えている状況です。

これらの作業は、言うならば単なる「リファクタリング」です。しかし、ドメイン駆動設計に関する書籍を読んだことをきっかけに、その考え方やパターンをもとにして、システム設計の改善の糸口・ヒントを得ることができました。

今後は、SwiftUIとビジネスロジックの接続を改善していくつもりです。 SwiftUIからビジネスロジックを排除し、ApplicationServiceをビジネスロジックとプレゼンテーションの境界として変えていくつもりです。

ドメイン駆動設計は、スタートアップやプロダクト開発初期にも適用できるのか #

ドメイン駆動設計の前提として、しばしば、ドメインエキスパートと一緒にシステムを組み上げることや、業務のワークフローが確立していることなどが挙げられます。また、スタートアップのような、ソースコードを大きく削除することがよく起きるようなプロジェクトには、ドメイン駆動設計は向いていないと言われます。私は「そう言うこともあると思うが、考え方やパターンは開発初期にも適用できるのかも」と感じています。

スタートアップではドメインエキスパートがいない場合があります。業務のフローも確立していません。システムの開発初期では、ドメインに対する理解が不足した状態で開発し始めることも少なくないと思います。そうすると、今回の私のようにロジックが分散・複製され、カオスな構造になっていきます。

それでも、リリースやテストを数回繰り返すうちに、削除されにくい機能だったり、ある程度固定化されたワークフローだったりが出てきます。ドメインに対する知識も深まってきます。そういったタイミングで、ある程度変化しなくなったロジックを、ドメイン駆動設計の考え方をベースにして移し替えておくという方法が採れるのではないかと思います。テストが導入してあれば、あとで移し替えることになっても安心です。その後になって、ドメインに対する理解がより深まった時、仕様が変わった時でも、対応しやすい構造になっている期待があります。

当然ですが、上で書いたようなプロジェクトでは、初めからドメイン駆動設計でシステムを構築していくのは難しいと感じます。ドメインモデルが見えていない状態で、ドメイン駆動設計はできません。しかし、仮に様々な要因からスピード優先で開発してきたとしても、部分的にドメイン駆動設計を取り込むことができるのではないかと感じました。また、ドメイン駆動設計に移した機能を後から削除することになったとしても、大きな問題が発生することは少ないのではないかと思います。

終わりに #

「アーキテクチャ考える以前に、やることやってるのか？」と言う疑問から始まったわけですが、結果的にドメイン駆動設計を知るきっかけになりました。ドメイン駆動設計の原著も読んでいなければ、入門書を読んだばかりの状態ですが、その影響を感じて開発しています。銀の弾丸ではないことは心に留めつつ、引き続き、新機能の開発・設計の改善に活かしていきたいと思っています。