2024年5月13日に開催された「みなさんの戦略的DDDを聞きたい！ vol.1」の発表資料です https://sencorp.connpass.com/event/315445/

DDDでレガシーコードに立ち向かうリアル / Reality of confronting legacy code with DDD

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

ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう ドメイン駆動設計（DDD）が近年関心を集めていますが、同時にこの設計思想は難しい、わかりにくい、という見方もあります。さまざまなプロジェクトでドメイン駆動設計を実践してきたかとじゅんさんが、サンプル課題をもとに、ユースケース分析、モデル設計といった基礎を解説します。 はじめまして、Chatworkでテックリードをしている、かとじゅん（ @j5ik2o ）です。 僕は2010年ころより、大小さまざまなプロジェクトでドメイン駆動設計、いわゆるDDD（Domain Driven Design）を導入した開発を実践してきました。ドメイン駆動設計を主題としたワークショップなども主宰していますが、最近では加速度的にこの設計思想への関心が高まっていると感じます。本稿では、なにかと分かりにくいドメイン駆動設計の基本を、架空の

はじめに 基本、自分用のメモです。 多層システムで構築されたウェブアプリケーションにおいて、DbContextやLoginInfoのようなリクエスト毎に生成・破棄し、全体で共有するオブジェクトを誰が生成し誰が破棄する責務をもつのか、またそれらを各オブジェクトがどこから取得するのかという問題を、DI（依存性オブジェクトの注入）を使って解決する、という記事になります。 既にDIを使い倒している方には今更な内容かと思いますが、私のように古いシステムのメンテナンスをしていた人には有用かと思います。 この記事をかいた理由 ASP.NETでDIコンテナ使ってDbContextを注入するサンプルをいくら検索しても、ControllerでDbContextを受け取っていきなりそこでDBにアクセスする初歩的な実装例しか出てこなくて、「コントローラでDB層にアクセスするとか、そんないい加減なシステムがあってた

ASP.NET MVC のスキャフォールディングを使うと、以下のように Entity Framework の DbContext をコントローラのフィールドに持つコードが生成されます。 public class CustomerController : Controller { private SampleDbContext db = new SampleDbContext(); // // GET: /Customer/ public ActionResult Index() { return View(db.Customers.ToList()); } } 単純なアプリの場合はこれでいいかもしれないですが、リポジトリパターンを使った場合では DbContext をどうやって持つべきかと悩む人が居ると思います。 変更追跡やトランザクションの観点的に、DbContext や Unit of

わかりやすくて最高だった「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」レビュー 「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を読んだところ、とても良かったのでレビューしたいと思います。 私の状況 まずこの本を読む前の私がどの程度ドメイン駆動設計について理解していたかご紹介します。 以前同僚が書いてくれたサンプルコードを手本にレイヤードアーキテクチャみたいなTypeScriptのLambda関数を書いている 「Service」とか「Repository」とかの単語を命名に使っているが、使い方あってるのか自信ない、というか意味をよくわかっていない 実装中「この構成でええんか？」と何度も思い悩む 時間かかるくらいなら雑にさっさと書いてしまったほうが良いのでは、と思うこともある。けどちゃんとしたコードを書きたいんや。 こういうのを読んで、テストしや

ドメイン駆動設計には興味を持ちつつエリック・エヴァンスのドメイン駆動設計は数年前に積んだまま、という状態で何年か立ってしまったのですが、新しくDDD の本が出ていたので読んでみたところよかったので紹介させていただきます。 ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 本書は、 『エリック・エヴァンスのドメイン駆動設計』（ISBN978-4-7981-2196-3、翔泳社）、 『実践ドメイン駆動設計』（ISBN978-4-7981-3161-0、翔泳社） に感銘を受けた著者が贈る、ドメイン駆動設計の入門書です。 （https://www.shoeisha.co.jp/book/detail/9784798150727 より。） というわけで、ボトムアップで理解出来る章立てで書かれたドメイン駆動設計の入門書です。 個人的には、ドメインモデルの組み立てをどうやればいいのか

こんにちは、プレックスの石塚です。 今回のブログでは弊社で行っているエンジニアの社内勉強会と、その中での学習をベースに業務中でトライしたことを6つ紹介させていただきます。 エンジニアの社内勉強会について DDD勉強会について トライしたこと 実装面以外でのトライ ユビキタス言語を作ってみた ドメインモデル図を書く 実装面でのトライ テスト方針の共通認識を揃えた 名前空間を分割する enumによるドメイン知識の表現 各レイヤーでの責務を明確にする おわりに エンジニアの社内勉強会について プレックスでは週1の頻度でエンジニアの勉強会をやっています。 テーマは社内で使っている技術やこれから導入を予定している技術など、ある程度の共通認識はありますが、比較的自由としていて、雑談ベースでカジュアルに決めています。 勉強会の形式はその時々で変わりますが、多いのは輪読会で、各自事前に書籍を読んできてもら

この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事

このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 November 2016 Volume 31 Number 11 データ ポイント - CQRS と EF データ モデル Julie Lerman コマンド クエリ責務分離 (CQRS) は、データの読み取りとシステム状態の変更 (たとえば、確認メッセージの送信とデータベースへの書き込み)、およびオブジェクトとアーキテクチャの設計の責務をそれぞれ分離することに関するガイダンスを提供するパターンです。CQRS は当初、銀行取引などのトランザクション数の多いシステムで役立てるために考案されました。CQRS は、Bertrand Meyer のコマンド クエリ分離 (CQS) 手法を Greg Young が進

SQL Server、Oracle、PostgreSQL など、リレーショナル データベースを使用するとき、Entity Framework (EF) に基づいて永続レイヤーを実装することをお勧めします。 EF は LINQ 対応であり、厳密に型指定されたオブジェクトをモデルに与えます。また、データベースにシンプルな永続性が与えられます。 Entity Framework は長い間、.NET Framework の一部でした。 .NET を使用するとき、Entity Framework Core も使用してください。これは .NET と同様に、Windows または Linux 上でも実行されます。 EF Core は Entity Framework を完全に書き換えたものであり、フットプリントが大幅に少なくなっており、パフォーマンス面で重要な改善が行われています。 Entity Fra

こちらのトークイベントで用いたスライドです。 『良いコード/悪いコードで学ぶ設計入門』著者トーク https://modeling-how-to-learn.connpass.com/event/242976/

ドメイン駆動設計とは開発手法の一つで，一言でいうと「オブジェクト指向プログラミングを最適化したもの」というイメージになる。 オブジェクト指向設計にはいくつかの原則と，有名なデザインパターンがいくつもあるが，オブジェクト指向設計という言葉が持つ意味は非常にあいまいさがあり，技術者それぞれで定義の異なるものである。 また，オブジェクト指向設計の原則やデザインパターンは，多くの指針や実装例が示されてはいるものの，ピンポイント的な実装例が多く，アプリケーション全体を示すものは少ない。保守性やテスト容易性を高めるために，アプリケーション全体をどのように作成し，どういったクラスをどこに配置するべきか？といったところまでは言及されていない。 そういったことはおそらく開発チームごとに話し合い，決定していくべき事なのかもしれない。ドメイン駆動開発とは，GOFのデザインパターンやマーチンファウラーのリファクタ

設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は

こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ

DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。 - 境界づけられたコンテキストがどこまでの範囲かよくわからない - ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？ - ドメインモデルがただのデータの入れ物になってしまう(貧血…