連載「過渡的設計に挑む」#2 pre リポジトリパターン

この記事はニーリーアドベントカレンダー2024の23日目 その2の記事です。

こんにちは、ニーリーの佐古です。

現在プロダクト統括本部内のARCHチームというチームでテックリードとして開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。
今回またその一例を 年末にチャレンジしたいことLT会 - connpassで発表した内容をもとにご紹介できればと思っていたのですがが、 その前に書籍紹介を。

書籍「進化的アーキテクチャ」の紹介

www.oreilly.co.jp

このような本が出ていることにこの連載の#1 をほぼ書き終わった後に知りました。
ちょっと触れずにはおけない内容ですので紹介しておきます。

訳者まえがきには、 この本はM. Fowler氏*1のブログ*2 の「Is Design Dead?」にある「進化的設計」を踏まえたものとあります。

その都度「必要十分な設計」を行いながら、時間の経過とともに少しずつ設計を洗練させていくことで、変化に適応しようというアプローチ

その進化的設計を推し進め、ビジネスの時系列的な進化とリンクしてプロダクト設計も進化させていくための手引きが「進化的アーキテクチャ」ということでした。

ということでテーマが非常に近く内容も充実しているので、
より俯瞰的なアーキテクチャ戦略のことに関してはこの本に任せてしまうのがふさわしく、 本シリーズのテーマはそのプラクティカルな実践例という立ち位置を取るのがよさそうですね。

「繋いでいき」の必要性

またこの本、学習曲線の話はあまり出てきません。
アーキテクチャがもつ「～性」の一つとして、学習可能性が単語として挙がるのみです。
PenultimateWidgets社*3のメンバーは真綿が水を吸うように学習できるのでしょうが、
現実に生きる我々としては学習負荷の軽減も踏まえた上で
「適応度関数」の出力を改善するような施策を打ち出していくのが好ましいと考えられます。
前回触れた「繋いでいき」の領域ですね。

と、シリーズ継続のエクスキューズを確保したところで今回の例です。

例: pre リポジトリパターン

業務と技術の事情を分けたいというお決まりのやつですね。

多分、理想形

リポジトリパターンです。 で、なぜここでステップを刻む必要があるかというと

「I/Fに依存しろ」の難しみ

リポジトリパターンというかDIでI/Fへの依存を義務付けたときに出がちな苦情として
「実装クラスが見えない」というものがあります。
これは2通りの理由が考えられます。

1. この方針自体に慣れていない
2. 設計が不適切でヨーヨー問題を起こしている

能動的な対応が必要なのは2番目の方で、
切り離してはいけない抽象にも現れるべき知識がI/Fの向こう側に隠れてしまっているなど
形だけI/Fと実装を分離したときに起きがちな困ったやーつですね。
「利用する側だけではなく、提供する側についてももうひと刻み必要ではないかな？」
という考えに至った次第です。

とりあえず、これでいく

いきなりコンクリートクラスとしてのリポジトリを提供する手というのも考えましたが、
DI自体の前にワンステップ踏もうということで
staticメソッドをリポジトリの代わりとして提供し、
オブジェクトの永続化処理を一点に集中させるアプローチを考えました。

処理のあちこちでオブジェクト自身の永続化メソッドを呼ばれることを防げば、 ある程度自然にユースケースのどのあたりで永続化処理が呼ばれるかもレビューしやすくなります。
また、永続化の事前条件はstatic永続化メソッド内で確保できるようになれば
改修漏れも減らせるでしょう。

参考

今後の展望

見ればすぐ問題点が分かるような設計なので、
あまりここの踊り場に長逗留することは避けたいと考えています。

• ある程度勘を掴んでもらう程度の普及活動
  • 各チームがリポジトリパターン導入の問題をクリアできそうな目途が立てば捨てます。
  • 現状の意図とあるべき姿の差分についての利害説き。
• 実装分離の方針に関する展開活動
  • もちろん目途を立てるのはこちらの仕事になります。
  • プラクティスは意図まで展開していくのが「寄り添っていき」活動です*4
• 別にレコードエントリと業務モデルが分離できているわけではまったくないのでその点のケア
  • レコードエントリの永続化処理に関する知識を分離集約「しやすく」しているだけ。