このエントリーをはてなブックマークに追加

PHPerKaigi2021にて「そのコード、フレームワークの外でも動きますか?」を発表しました。スライドを公開します。



説明に使用したLaravel版とSymfony版のコードは下記で公開しています。 説明した各リファクタステップごとにタグやブランチを切ってあるので、各ステップでコードがどのような状態になっていたか興味のある方は詳細を見てみてください。
https://github.com/77web/fortune-teller-laravel
https://github.com/77web/fortune-teller-symfony


このエントリーをはてなブックマークに追加

今年のPHPerKaigiは、3/26〜3/28の3日間、ニコニコ動画とDiscordを使って開催されます! https://phperkaigi.jp/2021/

この一年、ZoomやYouTubeLive、あるいはカンファレンス用のプラットフォームを使ったイベントには多数参加しましたが、ニコニコ動画を使うカンファレンスにははじめて参加します。 どのような体験になるかとても楽しみです。

3/28(日)の午前中、「そのコード、フレームワークの外でも動きますか?」というタイトルで発表します。 https://fortee.jp/phperkaigi-2021/proposal/43f0d237-e254-4836-8275-9027d27a80ef

12月のPHPカンファレンスのときは自分が話している間、リアルタイムにDiscordに書き込まれていたコメントを確認できず、後からまとめての返信になってしまったのですが、今回は事前収録済みなのでDiscordのコメントにもタイミングよく返信できるんじゃないかなと思っています。

チケットはまだ販売中のようなので、ぜひ今からでもチケットを入手して聞きにきてください!(オンラインのためか今年はずいぶんお求めやすくなってます!) よろしくお願いします!


このエントリーをはてなブックマークに追加

はじめに

カルテットの有澤です。 先日は 認識のズレを共有することのうれしさ を投稿させていただきました🙏

以前の記事は OOP研修 での物事を記事にしましたが、今回は「Symfony研修」を受けた際に気がついた物事を紹介します🙏

さて、カルテットでは開発者同士の知識の差を減らすために、 プロダクトコードのルートディレクトリに、指針とするアーキテクチャが記載されたドキュメントを配置する文化があると、研修の中で知りました。

その内容を読むと 「業務知識を持つクラス」と「サードパーティに依存するクラス」を分けられている ことに気づきました。

本記事では、どんな理由で分けているのか を紹介します😊

そもそも「サードパーティに依存しないクラス」は、なにがうれしいのか?

「フレームワーク自体に大きな変更があっても、影響を受けてほしくないドメインコードを守ること」 ができます。

Webサービスというものは、長く運用していくとフレームワークのバージョンを上げる機会が出てきます。 その際に「実装済の機能を、新しく追加されたコンポーネントに置き換えたい」シーンが出てくるかと思います。

これにより、何も対策をしていなければ、せっかく書いたドメインコードがフレームワークの都合で改修されてしまいます。 ドメインコードは業務の知識が詰まっているので、フレームワークの都合で業務の知識が変わるというのは、知識の変化として不自然だと考えています。

なので、このような変化を回避するために、 サードパーティ(外部コンポーネント)に依存しなくする ことで、ドメインコードを守るのが狙いです。

よりわかりやすく伝えるために、以下で図を使いながら説明します。

依存性を分けていない場合の構造

依存性を分けていない場合の構造の図

上記の図では、Serviceにドメインロジックが含まれているシステムの図です。 黄色いボックスは変更があったコンポーネントを指し、赤いボックスは影響を受けるコードです。

図のように、コンポーネントの変更に対し、コンポーネント関連のロジックが影響を受けてしまうのは、やむを得ないと考えますが、 ドメインロジックに関しても影響を受けてしまっているのわかります。

これではフレームワークの都合で、ドメインロジックが影響を受けてしまいます。

依存性を分けた場合の構造

依存性を分けた場合の構造の図

上記の図では、ドメインロジックを「Model」という層に追い出しています。 「Model」は、何に対しても依存していないので、コンポーネントの変更に対しても干渉していないとわかります。

この構造であれば、コンポーネント(サードパーティ)の都合でドメインコードを変更するような事態になりにくいと考えられます。

最後に

フレームワークのバージョンの変化に耐えられるように設計することは、今まで深く考えたことがなかったので、 研修の中で新しい視点に立つことができました👀

世の中にあるWebサービスというものは、プロダクトに纏わる物事によって寿命は大きく変わりますが、 せっかく作るシステムですから、長く運用できる工夫をプログラミングを通して表現していこうと思います😊