DDDの正体は実装パターンとモデリングの組み合わせ - パンダのプログラミングブログ
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
DDDを実践するための手引き（概論・導入編）
ナニコレ DDDは「Domain-Driven Design（ドメイン駆動設計）」の略語で、エリック・エヴァンスさんという人が考えるソフトウェア設計におけるプラクティスまとめみたいなものです。 『エリック・エヴァンスのドメイン駆動設計』というバイブル的な書籍がありますが、「途中で挫折した」「読んでもよくわからない」「よくわからないけど自分なりに解釈して実践している」というような感想をよく聞きます[1]。DDDの概念は幅広く、哲学的で、抽象的であるため、DDDをどのように解釈しどのように実践すればいいのかわかりにくいものです。 この記事ではそのような問題に悩んでいる人たちのために、数年に渡りDDD（的なもの）を実践してきた筆者が噛み砕いた（個人の独断的な）解釈と実践方法を解説します。 DDDってなぁに？ DDDがカバーする領域 DDDが言及する範囲はとても幅広いです。エリック・エヴァンスさん
DDD is dead. God is in Twitter #scrumsapporo
Scrum Fest Sapporo 2021でプレゼンしました。 私達の愛したDDDを取り戻すための苦悩と挑戦について紹介します。本作品はマリリン・マンソン Rock is dead オマージュ作品となっております。 DDDはその構造上、デザイン思考やリーンスタートアップやディスカバリーといったものを考慮しておらず、デリバリーフェーズを意識した手法になっているのですけど、これはチーム開発のボトルネックを生み出す原因になりがちではないでしょうか？ デリバリーにおいてはドメインを語れる人がいく人かおり、それをベースにそこそこの規模のシステム設計やアプリケーション設計をしていく。その過程でDDDを実践したという経験がつくわけですが、その人に対して、新規事業であったり、若々しい状態の事業のサポートをお願いすると、劣化したDDDのような設計をベースに進めつつ、現場のプログラマーを説得する行為に走る
DDDを試行錯誤しながら実践するチームの学びをまとめてみた - Gaudiy Tech Blog
こんにちは！エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドエンジニアをしている椿（@mikr29028944）です。 Gaudiyは、まだエンジニア10名、デザイナー2名ほどの開発チームですが、今年の6月からDDDと呼ばれるドメイン駆動設計を開発に取り入れました。 DDDとは、一言で言うとドメインエキスパートと呼ばれる担当業務やシステム設計に最も詳しい人と、エンジニアが共創してソフトウェアを開発する手法です。 今回は、DDDを実践する中での気づきや学び、躓きやすいポイントをどのように乗り越えてきたかについて、ご紹介してみたいと思います。 DDDを検討しているチームや、導入して間もないチームのご参考になれば幸いです！ 1.なぜDDDを導入したのか 2.GaudiyではどのようにDDDを取り入れているか 3.DDDの実践で生じた課題と乗り越え方 3-1.チ
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
プロダクトマネージャー目線で語る、0→1開発でDDDを取り入れた背景とその効果 - クラウドワークス エンジニアブログ
こんにちは！ クラウドワークスの新規事業開発チームでプロダクトマネージャー（以下、PdM）を担当している八尾です。 クラウドワークスでは、新規SaaSプロダクトを目下開発中です。 プロダクトの中身はまだ詳しく言えないのですが、新規事業の考え方などはこちらの記事をぜひご覧ください。 現在開発中のプロダクトでは初期からドメイン駆動設計（以下、DDD）の思想を取り入れて設計をしています。 DDDは、端的にいうと、ドメインモデルを中核に据えて設計しようということだと理解しています。 （参照：Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita） この記事では、なぜ初期の小さな規模のプロダクトでDDDを取り入れる意思決定をしたか、取り入れてみてどういう効果が得られたかについて、非開発者のPdM視点で書いてみようと思います。 （開発者視点でどうだったかは後々また公開する予定
なぜUserクラスは負債化しやすいのか “風刺動画”から理解する情報システム開発とモデリング
「“開発者体験”で世界をエンパワメントする1日。」と題し、チームや組織の課題に日々取り組む方々に向けて開催された「Developer eXperience Day CTO/VPoE Conference 2021」。ここで、READYFOR株式会社の仙塲氏が「『Userクラス』で考える技術的負債解消の観点」をテーマに登壇。まずは情報システム開発とモデリングの定義について紹介します。 クソコード動画『Userクラス』 仙塲 大也（以下、仙塲氏）：こんにちは。ミノ駆動と言います。不運な時間がやってまいりました。まじめなセッションだらけなのに、はたしてこういう動画を流していいものかと。完全にネタ枠です。 このセッションの説明です。多くのサービスで技術的負債になりやすい筆頭格として、Userクラスがあります。本セッションでは、Userクラスの負債により引き起こされる弊害を描いた、風刺動画を上映しま
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
過大評価されるDDD（ドメイン駆動設計）
この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計（DDD）は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア（TwitterやHacker Newsなど）で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし
Recoilで始めるお手軽フロントエンドDDD
はじめに React でコードを書いているとき、ある程度の規模のプロジェクトになると class を使いたくなりませんか？ 僕はバックエンドで DDD を用いている場合は、同じように Entity を宣言して使いたい場面が多々ありました。 しかし、React のプロジェクトで getter/setter を用いて値を変更しても残念ながら再描画はされません。 Redux の処理内や hooks 内で中途半端に class を用いても結局 DDD の設計思想をうまくコードに落とし込むのは難しいです...（どなたがご享受ください！） 今回は僕が Recoil を使ってフロントエンド DDD を手軽に実装する方法を共有したいと思います。 また、まだあまり技術記事で紹介されていないTypescriptでのサンプルコードやatomFamily, selectorFamilyの紹介も多く含んでいるので参
ドメイン駆動設計を導入するために転職して最初の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)
WEB アプリケーション設計入門 / Introduction to web application design
PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP については下記を参照ください。 https://nrslib.com/adop/ # Abstract https://fortee.jp/phpcon-2020/proposal/da5b9d99-e5a6-4f51-adea-1f1c10d99020 # Ref https://github.com/nrslib/scrum-app-sample-php https://github.com/nrslib/repository-support-php # URL Togetter: https://
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
糞コードと上手く付き合う技術 - Qiita
システムが大きくなり、要件が増え、ビジネスロジックが肥大化する。 数千行の処理が１つの関数に詰め込まれ、少しの修正を加えるだけで膨大な工数とデグレの嵐が巻き起こる。 誰しも経験したことはあるのではないでしょうか プログラマをクソコードで殴り続けると死ぬ こちらの記事には技術的連帯保証人というパワーワードが出ていました、言い得て妙だなと 糞コードは直すな。 注意： ここで述べている糞コードとは文法的にもっと可読性が良く、テスタブルに書ける可能性を秘めているコードではありません。（こちらは言語仕様勉強するのとリーダブルコードでも読んでください） 残念ながらすでに巨大な糞コードになったものをリファクタリングする技術についてではありません。 多分絶対的な正解はないと思います。 ビジネスロジックは足し算で共通化（条件分岐）すると死ぬ ユーザを更新するというupdate関数だとしましょう。 ここに何ら
ドメイン駆動設計によるシステム開発 | 知的資産創造 | 野村総合研究所(NRI)
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
Goはクリーンアーキテクチャの思想を活かせるか？ DMMのゲームプラットフォームにGo言語を選んだ理由
DMM GroupのGoの勉強会「DMM.go」。DMM Groupのエンジニアが現場で培った技術やトレンドについて発表していきます。 2回目の開催となる今回登壇するのは、合同会社EXNOA プラットフォーム開発本部の PFシステム部に所属する岡崎翔悟氏。「Goとクリーンアーキテクチャ」の内容で、実際の現場にいるからわかるGoの開発やクリーンアーキテクチャについて話していきます。関連資料はこちら。 合同会社EXNOAとは 岡崎翔悟氏：今回「Goとクリーンアーキテクチャ」と題しまして、EXNOAの岡崎が発表いたします。 「EXNOAって何だ？」と思われた方が多数いらっしゃると思うので、まずはそちらの説明から。DMM GAMESは2020年4月10日付でEXNOAに社名を変更しました。ただし、一般作品のブランド名として「DMM GAMES」は残っています。一般作品の「DMM GAMES」とR1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方 / buisiness_purpose_system_design
クソコード動画「Userクラス」で考える技術的負債解消の観点
Railsで考えるドメイン駆動設計のコアドメイン
