こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
「本日クラスターに入社したUnity Engineerが読む記事」の紹介 - Cluster Tech Blog
こんにちは、クラスターでUnity Engineerをやっている獏星(ばくすたー)です！ 突然ですが、この記事を読んでいるという事はあなたは本日クラスターに入社したUnity Engineerのはずです。 もし違う場合でも、「そうか、自分は本日クラスターに入社したUnity Engineerだったのか…」と受け入れて読んで下さい。ただし入社ツイートは無しで。 そして本記事を読んでいるあなたに朗報です。 つい先日、クラスターに入社したUnity Engineer向けの社内用オンボーディング資料として「本日クラスターに入社したUnity Engineerが読む記事」が作成されました！そのまんまのタイトルですね。 社内slackの投稿風景 クラスターではエンジニアのオンボーディングフロー改善に日々取り組んでおり、その一環として資料整備が進みました。 そこで今回は本日クラスターに入社したUnity
はじめに 本記事では、初学者向けにドメイン駆動設計（domain-driven design）についての、基本的な考え方と実装における基本概念について解説を行います。 ドメイン駆動設計（domain-driven design）とは？ ドメイン駆動設計とは、その名の通り "ドメイン" の知識にフォーカスした設計手法です。 ここで言う "ドメイン" とは、「ソフトウェアを使って問題解決しようとしている領域」や「プログラムを適用する対象となる業務領域」のなどを指します。 具体的には、会計システムにおける「金銭」や「振込処理」、SNSにおける「投稿」や「ユーザー」などが該当します。 これらのドメインを含め、システムが扱う業務仕様やビジネスルールを軸に設計を行い、 最適な業務実現・課題解決をしていこうという手法をドメイン駆動設計と呼びます。 ざっくり言うと、良いシステムを構築するための設計のベスト
はじめに BASE でプロダクト開発をしている @rry です。 さいきん BASE では 予約販売 App にて「長期の予約商品」を設定できるようになりました！ baseu.jp 🗓️予約販売期間が1年先まで延長可能 🧵製作や入荷に時間がかかる商品も取り扱いやすく 🎄季節の限定商品を事前に販売開始も◎ 今までの予約販売 App では最長で8週間までしか予約設定することができず、オーナーさんからのフィードバックでも「8週間先も設定できるようにしてほしい」という要望が多かったため、このたび予約販売長期化 PJ として機能改修を行いました。 この PJ の裏側を開発目線からご紹介していこうと思います。 PJ 概要 PJ キックオフから10/19リリースまでの期間：約8ヶ月 PJ メンバー：開発エンジニア 2-6人、QA エンジニア 1人、PM 1人、デザイナー 1人 アジャイル・スクラム
フロントエンドの複雑さに立ち向かう 〜DDDとClean Architectureを携えて〜 | さくらのナレッジ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
DDD熱が冷めて思うこと - Qiita
はじめに DDD(Domain Driven Design、ドメイン駆動設計)の学習は、とても難しいと思っています。多くの人が、DDDというのがあるらしい、と勉強を始めては挫折していったと思います。自分もそうでした。ある程度もがいてDDDの本を読んだりTwitterを追ったり自分で設計してみたりして、結局、自分がどのようなところに落ち着いたのか、などを書いてみたいと思います。下記の多くは自身の感想であり、主観を大いに含みます。 なぜ、難しいか 基本的に抽象的なことを扱っている上に、前提や語彙の定義があいまいなこと 歴史が浅いこと 具体例を表に書きづらいこと が原因だと思います。 基本的に抽象的なことを扱っている上に、前提や語彙の定義があいまい まず、数学のように厳密な語彙の定義がありません。もちろん数学ではないので当たり前なのですが、そもそも抽象的な話をするならせめて厳密に定義して欲しいも
はじめに この記事はHow to Design & Persist Aggregates - Domain-Driven Design w/ TypeScriptを翻訳したものです。 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです！ 設計に関する記事 この記事では、アグリゲートのルートを特定し、関連するエンティティの境界をカプセル化する方法を学びます。また、オープンソースのVinyl TradingアプリであるWhite Label上でSequelize ORMを使用して集約を構造化し、永続化する方法についても学びます。 これは、Domain-Driven Design w/ TypeScript & Node.jsコースの一部です。この記事が気に入ったらチェックしてみてください。 私た
Layered Design for Ruby on Rails Applications を読んだ時のメモ用
Layered Design for Ruby on Rails Applications 気になっていたので読んでみる。 zennのスクラップを使ってみたかった && 気になった箇所とか軽くメモしたり、感想を書いてみようかなと思った。 Chapter1: Rails as a Web Application Framework 概要 この章はRailsが用意してくれてる抽象化についての説明。 Railsがwebリクエストを処理するときの抽象化レイヤー バックグラウンド処理の抽象化レイヤー データベース周りの抽象化レイヤー の大枠3つ 気になったことメモ & 感想 trace_location (https://github.com/yhirano55/trace_location) のgem使ってみたい。 # こんな感じで特定の処理をtraceしてくれるっぽい TraceLocation
【ドメイン駆動設計】ビジネスの理解を促進させるドメインモデルという考え方とそれを取り巻く概念について説明する - Qiita
この記事は クラウドワークス Advent Calendar 2021 の 21日目の記事です。 はじめに こんにちは！ 欧州サッカーと総合格闘技と酒とドメイン駆動設計が好きなエンジニアの@d4teです。crowdworks.jpというプロダクトの施策チームでリーダーをやっています。 自分はドメイン駆動設計が好きで、その中でも解決すべき課題を明確にしソフトウェアの価値を高めるドメインモデルの考え方が好きです。 この記事ではドメインモデルの素晴らしさを伝えるべく、ドメインモデルとそれを取り巻く周辺の概念について説明していこうと思います！ ※ ValueObjectやRepositoryなどドメイン駆動設計の設計パターンについてはこの記事では言及しません。 そもそもソフトウェアを開発する目的って？ 多くの場合は「ソフトウェアによって何らかの問題を解決するため」と言えると思います。そして問題を解
はじめに ここ最近、ツイッター上でLaravelにおいてのRepositoryの実装についての記事や意見をいくつか見かけました。 それらの記事や意見の内容を整理しつつ、自分なりにLaravelにおけるRepositoryの実装について再考してみたいと思います。 Repositoryとは Repositoryは「エリック・エヴァンスのドメイン駆動設計」において紹介されているモデル駆動におけるクラスの一つです。 概要としては、ドメインモデルを永続化する処理を抽象化するために存在します。リポジトリは直訳で保管庫を意味します。 今回は最初にコード例を示した上で、Repositoryの実装について考えていきます。 参考: https://zenn.dev/kohii/articles/e4f325ed011db8 LaravelでRepositoryを実装してみる 設計 今回は、ユーザーを管理する一
はじめに 値オブジェクトの悩みポイントとどう付き合っていくかを見させていただいてのですが、 悩みがちな項目に Nullableな値を取り扱う場合 がありました。 NullObjectパターンじゃないの？と自分は思っていたのですが、ネットで言及している情報があまりなかったのでここが良いよっていう点を投稿してみます。 業務知識 以下のようなドメインで考えます。 Nullを許容しない値オブジェクト(ユーザーID) nullと空文字は別扱いしたい値オブジェクト(名前) DateTimeとかNullにできない値オブジェクト(生年月日) 選択肢系の値オブジェクト(性別種別) を用意してみました。 前提 値オブジェクトの抽象クラスには値オブジェクトを実装するを使用しています。値オブジェクトの特性を満たせていればなんでも良いです。 値オブジェクトの生成はstaticファクトリメソッド派です。 Nullを許
はじめに 本記事では、初学者向けにドメイン駆動設計（domain-driven design）についての、基本的な考え方と実装における基本概念について解説を行います。 ドメイン駆動設計（domain-driven design）とは？ ドメイン駆動設計とは、その名の通り "ドメイン" の知識にフォーカスした設計手法です。 ここで言う "ドメイン" とは、「ソフトウェアを使って問題解決しようとしている領域」や「プログラムを適用する対象となる業務領域」のなどを指します。 具体的には、会計システムにおける「金銭」や「振込処理」、SNSにおける「投稿」や「ユーザー」などが該当します。 これらのドメインを含め、システムが扱う業務仕様やビジネスルールを軸に設計を行い、 最適な業務実現・課題解決をしていこうという手法をドメイン駆動設計と呼びます。 ざっくり言うと、良いシステムを構築するための設計のベスト
プログラマが知るべき97のこと こんにちは。のんです。 本日はプログラマが知るべき97のことを読んでいてこれ「いいな」と思った箇所について書いてみようと思います。 こちらの書籍はとても有名なので、既読の方もいらっしゃるかもしれません。 そういう方は復習というか、内容を思い出したり、私の意見と違うところや共感できるところを探していただければ幸いです。 ボーイスカウト・ルールってなに？ プログラマが知るべき97のことにはこう書いています。 ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。 最近、私の町ではボーイスカウトの姿を見なくなってしまいました。私が子供の頃は友達がボーイスカウトしていたこともあって結構身近な存在だ
はじめに ValueObject作るのめんどくね。 DDDを学習してプロダクト開発をしたことがある人なら多くの人が考えたことがあるであろうValueObjectを全部作るのか、一部作るのか、全く作らないのか。 私もメンバーと議論したことがあるのですが、開発チーム内でValueObjectを作る基準が誰が見ても明確な場合はいいですが、新しくメンバーが増えたりパートナーさんを入れたりした場合には判断基準が合間になっていきだんだんと一貫性のないコードになってしまう恐れがあります。 しかしValueObjectをいちいち全部定義するのもめんどくさい、 そんな時のためにTypescriptのConstructorからValueObjectのスケルトンコードを自動で生成するライブラリを作りました。 ts-vo-generator type MountainType = { id: number; na
Javaのレコードクラス - Qiita
記事の目的 DDD（ドメイン駆動設計）では値オブジェクトはイミュータブルであることが求められる。 エンティティオブジェクトも可能であればイミュータブルとすべきである。 レコードクラスはイミュータブルであることが強制できるので、DDDと相性が良い。 DDDに限らず、オブジェクト指向でプログラミングするのであれば、予期せぬオブジェクトの状態変化でつまらないバグにハマることも無くなるので、オブジェクトは極力イミュータブルになるようにしたほうが良いと思っている。 世の中にはクラスに無条件かつ盲目的にgetter/setterをつくる思考停止なプログラミングが溢れていて、Lombokのようなライブラリがそのような悪いプログラミングの量産に拍車をかけている気がする。 「Lombokイコールすべて悪」とは言わないが、なぜそのフィールドがprivateなのか、本当にsetterが必要なのかを考えること無く
社内で「良いコード/悪いコード」の輪読会を開催した話
こんにちは！ koideです。 シェルフィーではチーム内の有志で輪読会を定期開催しており、今回は「良いコード/悪いコード」を読みました。 実際に開発したときに輪読会が役立ったエピソード 輪読会前後に担っていたIssueが外部サービスとの連携バッチのコード改善でした。 弊社にはDDDを取り入れたリポジトリがいくつかあり今回もその内のひとつでしたが、私はこの本を読むまではDDDが雰囲気でしか分かってなかったので、初めは理解するのが大変でした。 例えば、DDDの中でも「値オブジェクト（ValueObject）」といった概念がありますが、最初はこのクラスがある意味をちゃんと理解するのに苦労しました... 本書では値オブジェクトは以下のように説明されています。 値オブジェクト（Value Object）とは、値をクラス（型）として表現する設計パターンです。アプリケーションでは金額、日付、注文数、電話
普段Scalaを書いていますが、業務ではTypeScriptもフロントエンドで利用されています。※私はCSSが非常に苦手なのでほとんどフロントを触らないのですが。 バックエンドAPIは業務的なロジックに集中できて、DDD的な実装パターンなども適用しやすく結構綺麗に書けるのですがフロントエンドは要件が複雑になりがちで、その分コードも複雑になりがちです。また、バックエンドと異なり、UI/UXが中心になりコロコロ要件が変わるフロントエンドはバックエンドに比べてもリファクタリングする余裕がないことも多いです。 そうはいっても、少しでも綺麗に書きたいわけです。アンクル・ボブも言っています。 崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い —Robert C. Martin, Clean Architecture 達人に学ぶソフトウェアの構造と設計 と。 そこで今回は私がDDDを学んで
ValueObjectのススメ
こちらはKyash Advent Calendar 2023の22日目の記事です。 Kyashでサーバサイドの開発をしているdevkonoです。 この記事はドメイン駆動開発で良く利用されるValue Objectの特性について言語化し、最後に「Value Objectはいいぞ」とオススメするために書かれたものです。 今回は主にKyashでも広く利用されているGo言語を例にして記載します。 「Entityには振る舞いを持たせるのに、なぜEntityの中の項目自体には振る舞いを持たせないのか？」 と、考えたことはないでしょうか？ 一般的によく見かけるドメインエンティティオブジェクト（Value Objectを利用しない） Entityに振る舞いを持たせることは一般的に広く行われています。 以下にGo言語で実装された振る舞いを持たせたEntityを示します。 package sample imp
はじめに 業務においてクリーンアーキテクチャを意識してコードを日々書いていますが、「これってクリーンアーキテクチャの考えに沿うためにはどう書けば良いんだろう」と悩むことがあります。 今回はエラーハンドリングについて、クリーンアーキテクチャに則って考えてみたいと思います。 あくまで筆者一個人のいわゆる「ぼくのかんがえたさいきょうのエラーハンドリング」なのでエラーハンドリング時の一意見として参考になれば幸いです。 想定読者 Webのバックエンド開発においてクリーンアーキテクチャを意識してコードを書いているがエラーハンドリングに悩んでいる人 エラーハンドリングをするメリットを知りたい人 まとめ 基本的には型で例外をハンドリングするべきなので自作型を作ろう ドメイン層にHttpExceptionを書くな ドメイン層はプレゼンテーション層を意識しないため、エラーメッセージをAction層でコントロー
開発生産性向上への道： LIFULL HOME’Sのシステムアーキテクチャリプレイス - LIFULL Creators Blog
エンジニアの渡邉です。普段はLIFULL HOME'Sの売買領域のエンジニアチームにて技術リーダーとして開発を担当しています。好きなNginxのモジュールはngx_small_lightです。 ここ数年、LIFULLの開発部門では「開発生産性」と「品質担保」の重要性が再注目されています。 LIFULL HOME'Sの主要なリポジトリは、10年以上にわたり運用され続けており、数多くの開発者が日々の改善に尽力しています。 しかし、長年にわたる蓄積によって、アプリケーションの要件を満たすための実装が複雑化し、現在では実装時に調査、開発、レビュー、テストのすべての工程でそれぞれ必要以上に時間がかかる結果となっており、開発の生産性を低下させています。 この問題に対処するため、LIFULL HOME'Sでは既存のアプリケーションから必要に応じてシステムを切り出し、部門ごとでの運用管理を行っています。
freezed を使いこなしたメモ
Flutter で開発している際に、プッシュ通知のハンドリング部分で Freezed を使いこなしたので、そのメモです。 愚直な例から、ちょっとずつ freezed の機能を使いながらコードを進化させていきます。 サマリ unionKey を指定して sealed class を実現 必要なら unionValueCase を指定する fallbackUnion を指定して、未知の形式に備える カスタム JsonConverter を作って、プロパティを ValueObject として扱う @Assert でプロパティの制約を表現する @With や @Implements を使ってサブクラス同士を抽象的に扱えるようにする はじめに freezed とは、dart のデータクラスを便利にしてくれるコード生成ツールです。 dart の言語レベルでは提供されていない、copyWith 関数や、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
スタメンの技術的負債解消戦略 - stmn tech blog
ふわっと理解するDDD ~ドメイン駆動設計~ - Qiita
予約販売長期化 PJ の開発の裏側 - BASEプロダクトチームブログ
集約の設計と永続化の方法 -ドメイン駆動設計 - Qiita
LaravelにおけるRepositoryについて再考してみる
値オブジェクトのnull対応ってNullObjectパターンで良いのでは？ - Qiita
ふわっと理解するDDD ~ドメイン駆動設計~ - Qiita
ボーイスカウト・ルールを現実的に実現するためには? | のんラボ
TypescriptでValueObjectを自動生成する - ts-vo-generator -
TypeScriptでも値オブジェクトが書きたい - tchiba.dev
エラーハンドリングをクリーンアーキテクチャで書く場合に意識すること