タグ

DDDに関するimaizmのブックマーク (34)

  • 速習 AAA : Arrange-Act-Assert による読みやすいテスト - Qiita

    Assert.AreEqual("01234567-89ab-cdef-0123-456789abcdef", new Guid("01234567-89ab-cdef-0123-456789abcdef").ToString("D")); Guid のコンストラクタをテストしているのか、それとも ToString("D") をテストしているのか。 もしかしたら両方かも知れませんが、テストコードを見ても判断できません。 (意味のあるテスト名を記述していればそこで判りますが、だからと言ってテストコードが読み難くて良いとはならないので、ここでは GuidTest という曖昧なテスト名だったとします) Arrange-Act-Assert パターン Arrange-Act-Assert (AAA) パターンというのを訊いた事があるでしょうか。大まかには下記のようなものです: // Arrange

    速習 AAA : Arrange-Act-Assert による読みやすいテスト - Qiita
  • とにかくドメイン駆動設計を実践してみる試み ~TODO管理システム編~

    はじめに この記事はサービスを爆速で作ったり、ドメイン駆動設計の解説をするようなものではありません。 ドメイン駆動設計の勉強をしていて、手を動かす機会が足りないと感じていました。そこで、今の理解で実際に動くシステムをドメイン駆動で開発してみようと思いました。 記事はその開発の過程や考えていたことを記録したものです。 「この人はこういう形に落とし込んだんだな~」くらいで見ていただけたらありがたいです。 作成するシステム 今回作るのはTODO管理システムです。 初回の開発では以下の機能を開発しました。 TODOのタイトルと詳細を登録できる 作成したTODOを検索できる 選択したTODOの詳細を確認、完了、削除ができる デモ デモなのでメールの確認はダミーです。新規登録をしたら画面に出るメール確認リンクを踏めば確認済みとなります。 その後右上のログインからログインしてください。 デモのデータベ

    とにかくドメイン駆動設計を実践してみる試み ~TODO管理システム編~
  • 【イベント参加レポート】ドメイン駆動設計を導入するためにやったこと - RAKUS Developers Blog | ラクス エンジニアブログ

    ■ 目次 ドメイン駆動設計のプラクティスでカバーできること、できないこと 前提知識: DDDの目的 スムーズに進んだこと 苦戦したこと・していること プロダクトを活用していただくための取り組み まとめ 巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例 DDDの導入理由① コアドメインを定めて開発の費用対効果を高めるため 取り組んだこと 苦戦したこと DDDの導入理由② レガシーシステムの技術的負債解消 苦戦したこと 苦労していること 基幹システムの変更を楽で安全にする 参画していた案件 参画案件のテーマ 現場でやっていること 結果 感想 こんにちは 配配メール開発課所属 Jazumaです。 1/17 (月)にオンラインでドメイン駆動設計導入事例の勉強会がオンラインで開催されました。 modeling-how-to-learn.connpass.com 平日の夜にも関

    【イベント参加レポート】ドメイン駆動設計を導入するためにやったこと - RAKUS Developers Blog | ラクス エンジニアブログ
  • ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]

    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/

    ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
  • ドメイン駆動設計とイミュータブルなクラス設計

    クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ&集約ファクトリ

    ドメイン駆動設計とイミュータブルなクラス設計
  • DDDを実践するための手引き(概論・導入編)

    ナニコレ DDDは「Domain-Driven Design(ドメイン駆動設計)」の略語で、エリック・エヴァンスさんという人が考えるソフトウェア設計におけるプラクティスまとめみたいなものです。 『エリック・エヴァンスのドメイン駆動設計』というバイブル的な書籍がありますが、「途中で挫折した」「読んでもよくわからない」「よくわからないけど自分なりに解釈して実践している」というような感想をよく聞きます[1]。DDDの概念は幅広く、哲学的で、抽象的であるため、DDDをどのように解釈しどのように実践すればいいのかわかりにくいものです。 この記事ではそのような問題に悩んでいる人たちのために、数年に渡りDDD(的なもの)を実践してきた筆者が噛み砕いた(個人の独断的な)解釈と実践方法を解説します。 DDDってなぁに? DDDがカバーする領域 DDDが言及する範囲はとても幅広いです。エリック・エヴァンスさん

    DDDを実践するための手引き(概論・導入編)
  • DDD is dead. God is in Twitter #scrumsapporo

    Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやデ…

    DDD is dead. God is in Twitter #scrumsapporo
  • 実はDDDってしっくりこないんです - タオルケット体操

    DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

    実はDDDってしっくりこないんです - タオルケット体操
  • ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ

    はじめまして、ライクル事業部 エンジニアの菊池@kichionです。 普段の業務では主にエンジニアチーム運営・運用の課題解決やビジネスサイドとのやり取りが多く、中長期目線でのアプローチを行っています。 エンジニアとして行っている技術選定や実装関連についてはZenn - kichionにも投稿していますので興味があればご覧になってください。 今回はライクル事業部として少しづつ取り入れ始めている「ドメイン駆動開発」に焦点を当てて見ます (ドメイン駆動に関わる内容については、端的ですがQiita - kichionにも投稿してますので気になったらご参照ください) ドメイン駆動開発(DDD) ドメイン ドメインモデリング 技術的要素 ドメイン駆動開発の目的 ドメイン駆動開発を浸透させるための取り組み ドメイン駆動開発 勉強会 ドメインオブジェクト整理会 今後やっていきたいこと 続・DDD勉強会 現

    ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ
  • 🏗️ ドメイン駆動設計と依存性逆転の原則

    社内LTにて、ドメイン駆動設計と依存性逆転の原則を布教しましたʕ◔ϖ◔ʔ

    🏗️ ドメイン駆動設計と依存性逆転の原則
  • リーダブルコード by DDD / Readable Code by DDD

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

    リーダブルコード by DDD / Readable Code by DDD
  • スケールする要求を支える仕様の「意図」と「直交性」 - Qiita

    はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の

    スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
  • DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab

    株式会社ログラスの松岡です。 記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p

    DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
  • ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab

    この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

    ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab