組織が拡大しても質の高いDDDを守れるか？ログラス松岡氏・村本氏に聞くDDD浸透の切り札 2023年9月19日 株式会社ログラス　EM 松岡 幸一郎 新卒で日本アイ・ビー・エムに入社し、大手銀行向け業務アプリケーション開発に携わる。4年後にビズリーチに転職。社外サービスや社内業務システムの企画・開発を担う一方で、「ドメイン駆動設計」についてブログなどで発信し、勉強会も数多く主宰。DDD普及活動を通じて知り合ったログラスに転職し、EMを務める 株式会社ログラス　エンジニア 村本 雄太 新卒で人材系ベンチャーに入社し、インフラ責任者やテックリード、新規事業開発などの業務を担う。 2021年11月、ログラスに入社。スクラムチームのリーダーとして、チーム改善の推進や開発のリードを担う アジャイル開発の普及により、その関連手法であるドメイン駆動設計（Domain-Driven Design：以下、D

🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという

この記事はログラスDevチームAdvent Calenderの5日目の記事です。 SaaS開発のスタートアップ組織がスケールするためにこんにちは、株式会社ログラスの松岡(@little_hand_s)です。 ログラスは経営管理のSaaSを開発しているスタートアップ企業で、これまでアジャイル開発の手法としてDDD(ドメイン駆動設計)、スクラム、エクストリームプログラミングなどのプラクティスを適用しながら開発を行ってきました。 しかし、組織の規模が大きくなってきた(社員数が50人を超え、エンジニアチームも1チームから複数に分割されました)ことにより、それまでのスキルだけでは解消できない組織面の課題が生まれてきました。 そこで、今年の春から海外のアジャイルコミュニティで多く取り入れられている「システムコーチング®」という組織向けのコーチング手法を導入し、大きな手応えを感じているので、この記事では

株式会社ログラスの松岡(@little_hand_s)です。 最近、値オブジェクトに関して書かれているブログ記事を見ますが、 SNSなどにおいてDDDにおける値オブジェクトについて誤解されているような反応が見受けられました。 そこで、この記事では「DDDにおける値オブジェクトの位置付け」について解説し、具体的なモデル・コードを用いながら誤解を解いていきたいと思います。 なお、値オブジェクトに関する詳細な説明はここでは行いませんのでご了承下さい。 DDDの目的 まず最初に、DDDの目的について確認します。 DDDの目的は、モデリングを通じてソフトウェアの価値を大きくすることです。 これに関しては、こちらの記事で詳細に解説しているのでこちらをご覧ください。 ドメイン駆動設計は何を解決しようとしているのか - little hands' lab ここで大切なのは、モデルは一回のモデリングで完成形

記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ

ログラスでは、チームとして高品質なコードを追求するために「設計標準」というものを定め、チームで育てています。 この資料ではそのような取り組みについてご紹介します。 株式会社ログラス会社紹介資料 https://speakerdeck.com/loglass2019/whats-loglass ウラ凸 - シリーズA 17億円調達のログラスのウラ側へ、カジュアル面談で突撃しよう https://meety.net/articles/t2--zrl4ohf4gx6 外部公開している設計標準の資料 https://little-hands.hatenablog.com/entry/2022/01/28/programming-principle https://little-hands.hatenablog.com/entry/2022/01/24/domain-object-design

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/

エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management

Owners Experience Backend Group で Engineering Manager をしています、炭田（@tac_tanden）です。 BASE では決済などの複雑な事業ドメインに立ち向かうために、ドメイン駆動設計（DDD）を使った開発を進めているチームがあります。 そんな中で先日、DDD の有識者として松岡幸一郎(@little_hand_s)さんをお招きし、DDD モデリングデモ会社内で開催しました。 その模様をレポートします。 開催の経緯 BASE では日頃から DDD に関する質問ができるように、松岡さんを Slack チャンネルにお招きし、開発や DDD の勉強会で出てきた困りポイントや疑問を質問させていただいています。 そんな中で「DDD の勉強をしているけれど、モデリングを実際にどうするのか見てみたい」、「自分でモデリングにトライしてみたけれど、このや

リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する