こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービス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を追ったり自分で設計してみたりして、結局、自分がどのようなところに落ち着いたのか、などを書いてみたいと思います。下記の多くは自身の感想であり、主観を大いに含みます。 なぜ、難しいか 基本的に抽象的なことを扱っている上に、前提や語彙の定義があいまいなこと 歴史が浅いこと 具体例を表に書きづらいこと が原因だと思います。 基本的に抽象的なことを扱っている上に、前提や語彙の定義があいまい まず、数学のように厳密な語彙の定義がありません。もちろん数学ではないので当たり前なのですが、そもそも抽象的な話をするならせめて厳密に定義して欲しいも
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
スタメンの技術的負債解消戦略 - stmn tech blog
ふわっと理解するDDD ~ドメイン駆動設計~ - Qiita
予約販売長期化 PJ の開発の裏側 - BASEプロダクトチームブログ