こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提　〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継

1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が

「オープンセミナー岡山2022」のイベント登壇で用いた資料です。 https://okayama.open-seminar.org/

こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに？ コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ

「“開発者体験”で世界をエンパワメントする1日。」と題し、チームや組織の課題に日々取り組む方々に向けて開催された「Developer eXperience Day CTO/VPoE Conference 2021」。ここで、READYFOR株式会社の仙塲氏が「『Userクラス』で考える技術的負債解消の観点」をテーマに登壇。次にUserクラスの問題と、その解決方法を紹介します。前回の記事はこちらから。 Userクラスが抱える問題 ここでやっとUserクラスが抱える問題。Userクラスを今のモデリング観点と照らし合わせてみると、個人顧客と法人顧客の関心事の異なる問題を、たった1つのUserクラスで取り扱ってしまっています。つまり、複数の問題解決のために、Userクラスが流用されている構造です。特定の問題解決を意図した構造になっていないんです。 このユーザーというのは、個人でも法人でもどうとでも

この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任

本記事は ドメイン駆動設計#1 Advent Calendar 2019 19日目の記事です。 こんにちは、レガシーコードを 爆殺 リファクタリングするのが大好きなミノ駆動です。 今回はドメイン駆動設計導入上避けては通れない、大事な大事なお金の話を致します。 「ドメイン駆動設計を導入してみたいんです！」 部下「ドメイン駆動設計を導入してみたいんです！」 上司「それって何？なんのために導入するの？」 部下「…………」 はい、僕にもそんな時代がありました。 何のためにドメイン駆動設計を導入したいのか、簡潔に説明できますでしょうか。 「ドメイン駆動設計」のタイトルにあるように、本書は設計に関する書籍です。 ソフトウェア全体の設計手法や思想に関して言及している書籍です。 まずはソフトウェアの価値とは何か、設計とは何か、それぞれ何かを整理してみます。 ソフトウェアの価値 ソフトウェアが満たすべき要件

この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ