エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。 ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。 その経験則（100%ではないが多くの場合に役に立つ原則）の背景にあるエヴァンス氏の基本的な発想は次の５つに要約できると考えている。 ソフトウェアの複雑さは事業活動の複雑さに起因する 技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。 業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。 ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。 ドメイン駆動設計という設計のアプローチを取り入れ

Software Design (ソフトウェアデザイン) 2023年2月号 [雑誌] 技術評論社Amazon SoftwareDesign、ドメイン駆動設計入門もいいけど、ログの基本もめちゃめちゃいいので、今月号はみんな買ったほうがいいです— magnoliak🍧 (@magnolia_k_) 2023年1月19日 Software Design 2023年2月号、特集が「ドメイン駆動設計入門」と、「ログの基本」の2本立てなんですけど、どちらも凄く良い記事でした。 これは買った方がいいです！ ドメイン駆動設計入門 エヴァンスの「ドメイン駆動設計」で語られれていることをベースとして増田亨さんをはじめとする執筆陣による、とてもコンパクト、かつ分かりやすい解説が怒涛の密度で展開されます。この部分だけでも5000円くらいの価値が有るんじゃないでしょうか。 基本的な考えを把握する、という意味ではこ

本日(1月18日)発売された、Software Design誌 2023年2月号の第一特集で「ドメイン駆動設計入門」を書きました。 執筆の意図と記事の概要を簡単にまとめておきます。 Software Design 2023年2月号｜技術評論社 執筆の意図 特集のサブタイトルにある通り「設計力を磨きたい」読者が、ドメイン駆動設計の基礎を知ることで「設計の手法とアイデアの引き出し」を増やすことの役に立てればと思い執筆を引き受けました。 重視したこと 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない） 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務

はじめてScalaに触れたとき、変数宣言(var)と値宣言（val)を使い分ける言語仕様に、なるほどなあ、と思った。簡単に言えば、変数(var)は再代入できて、値（val)は再代入できない。 プログラミングのスタイルとして、var宣言は命令的なプログラミング、val宣言は宣言的なプログラミングになる。どちらのプログラミングスタイルで書いているかを、varとvalで明示できるわけだ。 Javaだと言語の基本の仕組みはすべてが変数。final宣言をすることで再代入をコンパイルエラーにすることはできる。Javaは、C言語やC++などの命令的なプログラミングの系譜の言語なのですべて変数(variable)というのは、とうぜんの言語仕様だった。 命令的なスタイルから宣言的なスタイルに 命令的なプログラミングでは変数(variable)を使う。宣言的なプログラミングでは値(value)を使う。 再代入

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

オブジェクト指向プログラミングが学べる書籍たち もし私が今から最初から学ぶならこの順番でこの本読むだろうという紹介です。 新人プログラマの方々は右も左も分からないというところからスタートとなるため、オブジェクト指向プログラミングを学ぶときに何から学べば良いか全くわからないという状況かと思います。 オブジェクト指向プログラミングを学んでいると自然と出会うドメイン駆動設計についても同様です。 そうした方々が書籍から学ぼうとした場合に、少しでも効率良く進められる順番を示してあげられれば良いなと思って紹介します。ただし、各書籍についての詳細な説明は書いていません（というか結構忘れててかけない）…。 なお、前提言語はJavaで言語構文にも十分詳しいことが大前提です。 以降、オブジェクト指向プログラミングはOOPと略します。 現場で役立つシステム設計の原則 OOPらしさの雰囲気がわかります 入り口に最

こんにちは。west-cです。 携わっている新規サービスにてドメイン駆動設計（以下、DDD）を取り入れた開発を行っていることから、去年の秋頃からDDDの学習をはじめました。 今回は、私が学習にあたり読んだおすすめ書籍を紹介します。 目次 目次 ドメイン駆動設計とは おすすめ書籍 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本 Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 実践ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 おわりに ドメイン駆動設計とは 本題へ入る前に、「そもそもDDDって何？」という方へ3行でとてもざっくりと説明します。 DDDとは、ソフトウェアで問題解決しようとする領域（ドメ

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！　Yahoo!ショッピングクーポンチームの小倉です。 前回のフロントエンド技術刷新の話とは打って変わり、今回は2019年に行ったバックエンド技術刷新の話です。 刷新前のシステムはノンフレームワークPHPのモノリスでしたが、現在は主にJava/Spring Bootでマイクロサービス化しています。今回は、その中でもっとも仕様が複雑だったマイクロサービスにおいて、ドメイン駆動設計(Domain Driven Design:DDD)を実践した話をご紹介します。 ショッピングクーポンの自由度を知る みなさんは、ショッピングの商品が割引になるクーポンをご存じでしょうか？　実は、クーポンには、ヤフーが予算をだして発行する「モールク

技術広報のsyoneshinです。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ　ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Jav

システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。

こんにちは。最近Slackのカスタム絵文字作りにハマっている友野です。Holmesでサーバーサイドエンジニアをしています。 Holmesが提供するホームズクラウドは、今年8月にサービスローンチ3周年を迎えました！ これまでの支持に感謝し、これからも長く使ってもらえるようにプロダクト改善に取り組んでいます。そのひとつとして、ドメイン駆動設計（以下、DDDと表記します）適用に関する取り組みについてご紹介します。似たような状況や同じ課題を持つ誰かの一助になれば幸いです。 背景と現状 まずはじめたこと 戦略的モデリング そして、戦術的な設計 採用するパターン2つ ドメインモデルを反映したオブジェクトを置くパッケージの作成 既存テーブル構造に依存しないRepository+Adapterパターン ふりかえり まとめ 最後に 背景と現状 ホームズクラウドはPMF（Product Market Fit：

銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/

こんにちは！ はじめまして！ 2020年7月からPIECE事業部でエンジニアをさせてもらっています。 野澤です。 今回、PIECEというサービスのリニューアルを担当させてもらったのでその時のことについて書きたいと思います！ まだ若輩者なので至らない点が多々あると思いますが フルリニューアルってどんな事したんだろう〜？ Hajimariのエンジニアはどんな仕事をしてるんだろう〜？ って思った人はぜひ読んで見てください！ ※ドメイン駆動設計の説明も書いたのですがボリュームが多くなってしまいました… ドメイン駆動設計について概要知りたいという方は是非読んでみてください。 クリーンアーキテクチャの説明やモデリングのやり方などは説明していません。 ご了承ください。 PIECEリファクタリングプロジェクトの概要 PIECEとはどのようなサービスなのか リニューアルの目的 リニューアル施策 ドメイン駆動

設計コース2回めを受けてからだいぶ時間が空いてしまいましが、2回めの内容のまとめと自分なりのメモを取っていたので、噛み砕き反芻するための記事とします。また、3回めを受けた後にまとめているので、3回目の内容を含みながらの考察になります。自分のためにまとめたので、本文はですます調ではなくなってしまって読みにくいと思いますが、ご容赦願います。 設計コースでの参考にする書籍3冊の設計アプローチ 設計コースでは下記3冊の内容に触れながらコースが進められる。 ソフトウェアシステムアーキテクチャ構築の原理（SSA） エリック・エヴァンスのドメイン駆動設計（DDD） オブジェクト指向入門 第2版 原則・コンセプト（OOSC） 第2回の最初の内容では上記3冊の設計アプローチについての説明があった。 ソフトウェアシステムアーキテクチャ構築の原理 特定の設計アプローチを取り扱っているわけではなく、設計における課

登録日2010/01/10（5232日経過）記録初日2010/01/10（5232日経過）読んだ本3104冊（1日平均0.59冊)読んだページ365178ページ（1日平均69ページ）感想・レビュー1184件（投稿率38.1%）本棚3棚性別男血液型O型職業IT関係現住所東京都外部サイトTwitterURL/ブログhttp://oshiire.to/

要件定義・仕様化・実装の継ぎ目をなくす開発手法。 ビジネスロジックを軸に組み立てる。 値の種類（型）に注目してモジュール化するRead less

RDRA をやってて思うところ。 RDRAでは多くのダイアグラムが定義されていますが、これらのダイアグラムはきっと成果物（最終的に作るものの中核にあるものをこう呼んでみる）では無いです。多分ハマりどころ。 システムコンテキスト図も業務フロー図もユースケース複合図も、どれもRDRAのエディタとビューアでしかありません。中間成果物、もしくは補足資料的な位置付け。 じゃあ成果物が何かって言うと、各アイコンと関連線。詰まるところ全てのアイコンと関連線を持ったリポジトリそのものが成果物なんだと思います。 ダイアグラムを通してリポジトリを読み書きしている感覚。アイコンを見つけやすい、関連線を引きやすいダイアグラムを使ってアイコンを配置し、アイコン間に関連線を引く。その整合性を確認しやすいダイアグラムを使って、アイコンと関連線を検証する。各ダイアグラムはそのためのものでしか無い。 決して「ダイアグラムを

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開