"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
![DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁](https://cdn-ak-scissors.b.st-hatena.com/image/square/968774fee18738187a1a1dc218bf1d36dc0d97db/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff835d9096b5040a6ad118d72c362e420%2Fslide_0.jpg%3F29436710)
DDDではよく「モデリングが重要だ!」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、DDD(ドメイン駆動設計)を用いて開発を行っています。(ちなみに、技術スタックとしては、Ruby製WebフレームワークであるHanamiを採用しています。Hanamiについての話が気になる方はこちらからどうぞ。) 今回は、弊社のDDDの活動の中でも、ドメインモデリングの取り組みについて紹介していきたいと思います。 実際に1年ほど運用してみて、ある程度、弊社の中で型が決まってきたので、その型を共有したいと思います。 本記事を読んで、「ユビキタス言語ってこういう風に作っているのか」「ビジネスサイドをこういう風に巻き込んでいくのか」ってところを感じとっていただけると嬉しいです。 ※ そもそもドメインモデリングという言葉を聞いたことがない、という方にもわかる
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか? ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一
Builderscon Tokyo 2019 の発表資料です。
エヴァンス氏の『ドメイン駆動設計』の背景にある基本アイデアは何かという私の捉え方のメモ書き。 ドメイン駆動設計にはいろいろな側面がある。また書籍『ドメイン駆動設計』は体系だった設計方法論ではなく、設計の考え方とやり方を経験則として言語化してみた、と捉えている。 その経験則(100%ではないが多くの場合に役に立つ原則)の背景にあるエヴァンス氏の基本的な発想は次の5つに要約できると考えている。 ソフトウェアの複雑さは事業活動の複雑さに起因する 技術的な複雑さもあるが、ソフトウェアが複雑になるのは対象領域の複雑さが主たる理由という考え方。 業務アプリケーションであれば、事業活動の複雑さが業務アプリケーションの複雑さの原因と捉える。 ドメイン駆動設計は、この事業活動の複雑さに起因するソフトウェアの複雑さをうまく扱うための工夫、というのが私の捉え方。 ドメイン駆動設計という設計のアプローチを取り入れ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く