PHPでのクラス設計（DDD/CQRSなど）の経験談を語ります

■概要 オンライン家庭教師マナリンク（https://manalink.jp/）でのPHPを用いたクラス設計の経験談を語ります。 ■私について サービス開発が好きなWebエンジニア。フロントエンドからインフラまでフルスタックに開発します。フロントエンドが一番得意。ゼロイチの立ち上げが好みです。 2016年株式会社LIFULLに新卒入社、新規事業の立ち上げやHOME'Sの開発を経験し、2019年に株式会社NoSchool CTO就任。ピボットを経てゼロからオンライン家庭教師マナリンクを立ち上げ、2023年末時点で社員10人超、売上ベースで年200％前後の成長率で事業をグロースしています。 趣味は将棋（アマ二段）、カメラ、ラム酒、筋トレ、高校野球観戦。 ■話題候補 ・DIコンテナの利用：外部サービスへのアクセスやDB操作をInterfaceを介して疎結合にして、インスタンス生成をDIコンテナに任せている。テスタビリティを高めたり将来的な具体実装の移植に備える。単にInterfaceを切るだけでなくモジュール名や引数の設計にも気をつけることで、本当の意味での疎結合を達成する ・ドメイン層の切り出し：Entityなどの実装パターンを用いてドメイン知識を切り出している。切り出されたクラスが知識を保有しており、外からは問合せや状態更新などが行われ、純粋なGetは永続化以外では行わない ・インフラ層の切り出し：上記に関連して、代表的なインフラ層の処理であるDBアクセスはRepositoryに切り出されている。単に切り出すだけでなくInterfaceがドメインオブジェクトになっており、関数はCRUDのようなシンプルなものしか有しないことでドメイン知識がインフラ層のコードに現れないようにしている ・CQRSパターンの実践：ドメインオブジェクトをGet APIで用いるとPresentationの知識（フォーマットなど）を有してしまうなどの背景から、Get特有の処理はQueryとして切り出す。QueryとCommandで共通のDB知識を求められる場合はORMの機能を活用して共通化 ・ユースケースクラス：ユースケースクラスはユースケースごとに作成し、原則1クラス1Publicメソッド

こんな人と話したい

１）普段バックエンドでドメイン駆動設計やクリーンアーキテクチャなど、所定の原則に基づいて開発している方 どこまで原則を守れていてどこから破ってしまっているかや、実際問題チーム開発でどの程度秩序を保てるか、あとドメインに関する単語の統一、さらに大枠でどういった事業特性なのでソフトウェアアーキテクチャに投資する意義があるのか、など議論しましょう ２）普段バックエンドだけどトランザクションスクリプト中心の方 実際トランザクションスクリプトでもそうそう困ることはないのでは？という印象もあり、トランザクションスクリプトで破綻させないためにやっていることや、実際破綻しているので設計をどこを頑張ることで改善できるかなど議論しましょう ３）普段フロントエンドをやっているなどの理由で、バックエンドの経験が薄い方 ぜひ僕の理解促進のために説明の練習相手になってください！一通り解説するので、よくわからないところ、わかったところ、間違っていそうなところを教えてください。

面談時間

タグ