こんにちは！askenでバックエンドのエンジニアをやっている澤路です。
以前のブログにも書いた通り、今askenはPHPで作られた既存システムをKotlinを使ってリアーキテクチャしています。 4月から9月までは実際に作り始めるまでの準備として技術検証をしてきました。この技術検証では、既存システムの分析から実装までのプロセスでaskenとして新しい方法を試してきました。
そこで、一緒に技術検証をやってくれているミライトデザインから林宏勝さん、鈴木ほげさんに参加していただいて、 これまでの活動での取り組みや学びを、それぞれの目線で発表する勉強会を行いました。
このブログでは、その勉強会の内容を簡単に紹介するとともに、当日答えられなかった質疑応答の内容をまとめています。
①asken リアーキテクチャを行う背景とDDD導入戦略 (村上 英誉@asken)
マネージメントの目線で、askenのリアーキテクチャを進める上でのおおまかな戦略を話しています。 なぜリアーキテクチャをやるのかといった背景、リアーキテクチャの進め方についても解説しています。 抽象度が高い話になりがちなので、具体的なイメージを持っていただけるよう過去の失敗談なども交えて紹介しています。
②ドメインと中心においたシステム開発 (林 宏勝@ミライトデザイン)
コンサルタントの目線で、今回のプロジェクトにどの様な考えで進めているのかを解説しています。 理想と現実を比較しながら、実際のプロダクト開発現場での取り組みや、プロジェクトの成功の考え方、目的はドメインを中心においた開発であってエヴァンス本のパターンを当てはめることではない、と言ったことを説明しています。
③リアーキテクチャによってどうなりたいか (鈴木 ほげ@ミライトデザイン)
エンジニアの目線で、リアーキテクチャ後に目指しているソフトウェアの構造を、その理由とともに説明しています。 具体的な事例で、パッケージ図、疑似コードを使って、レイヤードアーキテクチャとドメインの構成要素の解説しています。 特に観点を追加する毎に、パッケージ図が更新されていく説明は非常にわかりやすかったです。
④RDRA, ICONIX, DDDの実践から得た学び (澤路 寛之@asken)
RDRA, ICONIX, DDDの初学者目線で、この4ヶ月間の経験を通じた学びを解説しています。 各方法の自分なりの解釈や具体的にやったこと、実践後の自身の学びについてお話ししています。
発表の間に色々な質問をもらいました、その一部を紹介します。
質疑応答
Q: PoCでドメイン層とアプリケーション層を作って検証するを3回繰り返す中で、どのようなところが改善されていったのか教えていただけますでしょうか。
3回の検証は「あすけん」のコアドメインと呼べる複数のドメインを対象に行いました。1回目は食事記録ドメイン、2回目はアドバイスドメイン、と言った感じです。 それぞれ異なるドメインを対象にすることで設計と実装における幅広い課題を洗い出すことを1つの目的としていました
その目的通り、多くの課題が発見され方針を決めることが出来ました。 例えば、下記のようなものがあります。
既存システムはFat Controllerになっており、1つのコントローラで複数のユースケースを扱っていました。 それを分析しユースケースを分離することで、手続き処理の部分はかなりスッキリと整理することができました。
データモデルとドメインモデルが異なるので、データモデルをどうやってドメインモデルに落とし込むのかを検討しました。 理想的な実装が出来ない箇所をどう実装するかの妥協点を議論するることで方針が決まりました。
Q: PHP→Kotlinとリアーキテクチャをする際に、（それまでのアーキテクチャがどの様な構造だったかにもよりますが）言語が違うと部分的に置き換えていくのも難しくなりそうですが、 どの様に置き換えを実施していく計画（既に実践中？）なのか教えていただけますでしょうか。
具体的な部分に関しては検討中です。 大まかな流れとしては、APIやコンテキストの単位で徐々に新しいAPIに切り替えていくことを考えています。 ストラングラーフィグパターンのような形を取る予定です。
Q: プロダクトの開発をとめて、リアーキテクチャに集中していますか？それとも両方同時に進めていますか？
両方同時に進めています。 システム自体も大きく、結構長い期間をかけてリアーキテクチャを行うことになると思っています。 その間に全く開発を止めてしまうというのは、ビジネス的に難しいので、両方同時に進めて行く予定になっています。 ただし、リアーキテクチャする部分とプロダクトの開発する部分を効率よく出来るように、部分的に開発を止めるようなことは行なう可能性はあります。
Q： 段階的にリリースするとPHPとKotlinが併存する期間があると思うのですが、どのような移行戦略をとっていますか？
まさに今検討しているところです。プロダクトチームがPHPとKotlin両方メンテをする局面がどうしてもできると思います。 ・新機能開発、リアーキテクチャ後の既存機能への仕様追加はDDDの新アーキテクチャ(Kotlin)で新規開発 ・リアーキテクチャ前の既存機能への仕様追加はPHPの旧アーキテクチャ(PHP)で実践 新アーキテクチャで開発する際は、序盤はリアーキチームが開発をすることになると思います。 メンバーの育成、ローテーションなどを通じて、徐々に既存のプロダクトチームでの開発ができるようにしていく予定です。
Q: 録画は後ほど共有されますでしょうか？
ミライトデザインさんとaskenのYoutubeでアーカイブが配信されています。
Q： RDRAやDDDはビジネスサイドと一体となって開発することで効果を発揮すると思うのですが、askenさんではビジネスとエンジニアの関わり方を変えましたか？ もしそうである場合どのようにして変えましたか？組織体制に関する課題はありますか？
リアーキテクチャ起点ではないのですが、今年度からプロダクト組織化を実践しており、ビジネスサイドとエンジニアが同じ部門に所属し、同じプロダクトチームとして活動しています。
この試みを通じてプロダクトマネージャー、エンジニア間の会話が圧倒的に増え、DDDが効果を発揮する土壌を育てていると考えています。
askenの組織については下記のブログを参照していただくと、少し詳しく分かると思います。
Q： １つ質問です！！ 先ほどのFactoryの話の部分で、集約があるパッケージにFactoryを配置した理由のところをもう１回だけ説明していただけますか？
集約の生成時には計算が行われたり、不整合のチェックが行われたりします 例えば 100g のタンパク質は何カロリーとして計算するか、身長と体重の整合性 ( = BMI ) は問題ないか、というコードが関係します これらの処理はビジネスサイドの人と共有するサービスの仕様なので、DB を責務とする Infrastructure や手続きを責務とする Application ではなく Domain で書きたい、というのがモチベーションです
Q: askenさんには元々Kotlin製のプロダクトもあったのですか？PHPからKotlinに移行するにあたり、組織としてKotlinのナレッジを蓄積するための施策をご教示いただきたく。
MobileアプリでKotlinは使用していますが、サーバサイドKotlinは初です。 ナレッジ蓄積は検討中ですが、既存のプロダクトチームメンバーがリアーキチームに留学して、やり方を学んだ後自身のチームに持ち帰る暖簾分け方式を採用することになると思います。 留学するまで基礎力のアップは必要です。基礎力のアップには、書籍、社内勉強会による知識のインプット、練習問題にて実際にソースコードを書いてコードレビューを通じてフィードバックをする流れを想定してます。
Q: 集約同士を直接依存させるかわりにDomainServiceを使って関連づけると、DomainServiceが増えたときに、 集約同士の依存を把握するのが難しくなってくると思うのですが、どのような対策がありますか？
確かに、コードから把握すると依存関係を把握するのは難しくなると思います。 コードから依存関係を把握するより、モデルやクラス図から把握するようにしたいと思っています。
Q: リアーキテクチャの期間見積もりはどのようにやりましたか？
API毎に3段階で規模を見積もり、それぞれに対して工数を掛け合わせることで期間の見積もりを出しました。各規模の工数はPoCでの結果を元に決定しています。 かなり大雑把な見積もりにはなっていますが、仕様や設計を整理しながら進めるというリアーキテクチャの特性もあり、この様な見積もり方にしています。 ただし、これが最終版の見積もりというわけではなく、実装によって得られた学びを元に見直しをしてく予定です。
最後に
「asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX」というテーマで開催した勉強会の内容を簡単にですが紹介しました。 askenのリアーキテクチャに関わるメンバーのそれぞれの視点からの発表は、私としても色々な視点からの話が聞けて学びの多い会でした。 参加していただいた方々にも得るものがあれば幸いです。
ミライトデザイン 林さんの発表でもありましたが、今回の勉強会は「リアーキテクチャはこうしていこうと思っている」という話が多かったので 今後、リアーキテクチャを進める中でどう変化していったかをまたどこかで共有できたらなと思います。
お知らせ
askenでは、設計やアーキテクチャにこだわって開発をしたいエンジニアを募集しています。
