2024年5月13日に開催された「みなさんの戦略的DDDを聞きたい！ vol.1」の発表資料です https://sencorp.connpass.com/event/315445/
戦略的DDDは重いのか？ / Is strategic DDD heavy?
2024年5月13日に開催された「みなさんの戦略的DDDを聞きたい！ vol.1」の発表資料です https://sencorp.connpass.com/event/315445/
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
どうやら本当のデスマーチを教える時が来たようですね - Qiita
この業界、デスマーチという用語が安易に使われすぎていると私は感じています。自虐的な表現が好きな日本で、この言葉はとてもウケが良かったのでしょう、他の IT 系ことわざに比べて極端に有名です。 が、そのために誤用も増えてきました。たんに自分の仕事がきつい状態になることを「デスマってる」と表現する人がいますが、本当のデスマーチはそんなものではありません。まず、「マーチ」である以上、個人の問題ではないというのが最重要点です。 デスマーチとは組織の病です。ソフトウェア開発プロジェクトを計画するトップが未熟だと、その素人見積のせいで、見えていない部分の労力に予算と時間を確保されないまま、プロジェクトがスタートしてしまいます。冷静に考えて、リソースが半分しかなければ、50% 以上の進捗が出るはずがありません。愚かな組織人はなぜか、その明らかな失敗を見通す合理的判断をタブー視し、不可能な催促をしたり、品
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog
こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 本記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン（業務活動）にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ
DDD is dead. God is in Twitter #scrumsapporo
Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？ デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
フロントエンドとオブジェクト指向
フロントエンドの実装にオブジェクト指向をどのように取り入れるかを考えます。 動機 近年のフロントエンドは、Reactなどのフレームワークを使ったコンポーネントベースの設計が主流だと思います。コンポーネントは、HTMLによるマークアップ、CSSによるスタイリング、JavaScriptによる振る舞いがひとまとめにされた、再利用可能な部品です。 コンポーネントの設計を考えていると、次のような疑問が生じます。 何を基準にコンポーネントで分割すればよいか。 コンポーネントの粒度はどれくらいが適切なのか。 どのタイミングで抽象化すれば開発コストが無駄にならないか。 分業した際にコンポーネントの分割や粒度の基準をどのように統一するべきか。 そこで、いろいろ調べたり試したりしたところ、フロントエンドの設計にオブジェクト指向を取り入れることが、これらの答えの一つになるのではないかと考えました。 この記事では
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
「DDDで複数集約間の整合性を確保する方法」に対する考察 - かとじゅんの技術日誌
久しぶりにブログ記事を書きますか。 ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。 この記事は古くなったので、ぜひ以下も参照してください。 blog.j5ik2o.me little-hands.hatenablog.com 題材も松岡さんのブログ記事と同じもので考えます。 「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。 注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。 class CreateTaskUseCase1( private val taskRepository: TaskRepository, private val taskReportRepository: TaskReportRepository
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
「DDD をやっている」とは
脳内整理のため、つまり僕のためのポエム 自分の中で理解が一区切りついた感じがしたので、コミットしておく 「DDD をやっている」に対して感じていた違和感 DDD を始め ( させられ ) て以降感じていた違和感がある 僕にはこんなフレーズが頻繁に聞こえていた 若干文面は違うだろうが、弊社に限らないニュアンスだとは思う これらに対するモヤっとを解消したいのでいろいろ考え直してみた 曰く「DDD だと仕様とモデルが一致する」 第一印象 いや、テキストと絵は一致しないっしょ？ そもそも一致ってなにさ？ 仕様書を Java で書くってこと？ それとも実装を日本語でするってこと？ 曰く「DDD だと業務の文章でコーディングする」 第一印象 業務の〜もなにも文章は全部日本語じゃん？ そもそも、じゃあ DDD でなければ何の文章で実装していると仰るの？ 曰く「DDD だと変更に強い」 第一印象 DDD
ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか？ 実は、クーポンには、ヤフーが予算をだして発行する「モールク
Blitz.jsをRuby on Railsエンジニアが触ってみた感想
感想です。 何をしたか 現状でBlitz.jsで本番サービスを運用できるかの調査。 Railsで運用している本番サービスの一部機能を、3日間ほどかけて移行を試してみた。 結論 (Railsの主戦場でもある)新規事業開発の文脈でのクイックな立ち上げを想定するなら、本番運用するにはまだ厳しい。 特に、RailsユーザーとしてはActiveRecordがないのが厳しい。 開発効率そのものはRailsと比べて多少落としても、Railsよりもスケーラブルで型安全に開発したいなら、割と良い選択肢に思う。 もろもろ可能性は感じるので、引き続き応援していきたい。 良かった点（＝Blitz.jsに興味を持っている理由） 型安全な開発 サーバーもフロントも全てが型に守られた開発、そしてIDEの恩恵を受けられるのは、いうまでもなく心地がいい。 型は補助輪のようなものなので、ユーザースキルが高ければ必須ではないく
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
DDDとORMのEntityを混同しないための考え方
２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi
ソシオメディア | OOUI – オブジェクトベースのUIモデリング
最近、OOUX という言葉を見聞きしました。これはオブジェクト指向の利用者体験（Object-Oriented User Experience）のことで、いくつかの記事を読んだところ、アプリケーション設計において画面とデータを対応づける際にオブジェクトを手掛かりにするという方法論のようです。つまり OOUX は「オブジェクトベースのUIモデリング」と言い換えることができそうです。そうすると実は以前からそのようなデザイン手法はあり、「OOUI（オブジェクト指向ユーザーインターフェース）」と呼ばれていたのです。最近になって OOUX という言葉が使われるのは、OOUI のことを知らなかったか、もしくは流行語である「UX」を用いた方がかっこいいと考えたからではないでしょうか。 「オブジェクトベースのUIモデリング」というデザイン手法は、GUI アプリケーションをデザインする際の基本的なテクニック
イベント・ソーシングを知る
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ベロシティを上手く使って 技術的負債を計画的に解消する
マンガではわからない ソフトウェア開発の真理 | ドクセル
