2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =

前回：ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前回のさいきょうパターンの検証結果 まずは前回のさいきょうパターンですが、会社内の勉強会で実装を進めて行ったところ、少し整理されてこのようになりました。 Entity（図中model）はExternal層で使えるようにImmutable.jsのRecordを使って実装 ReadOnly、副作用NGという意図 ○ React+Redux的には使いやすかった × mutateメソッドで複製が作れてしまうため、"見るだけ"の意図を突破できちゃった UseCaseはredux-thunkを用いたThunkActionで実装 ○ CleanArchitectureを意識しないで作っていた頃に似た形で実装できた × Storeの構造に依存してしまった re-ducks構造が合わなかったので廃止した re-du

続編を書きました！ 続・ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前書き 最近話題のFluxにおいてモデルをどう扱うのかについて、自分もたまたま似た課題に取り組んでいたのでアウトプットしてみたものです。 まだ検証段階なのであれこれコメントいただけると幸いです。 タイトルは、、一度書いてみたかっただけです（照 発端 扱っているプロダクト（UI）のメンテナビリティ、エンハンサビリティが低い 業務ロジックとUI制御ロジックの分離がうまくできておらず、 ちょっとしたUI改善でも業務ロジックの考慮が必要な状況。 SPAになりさらにUIのコードは複雑化してきている UIだから複雑なアーキテクチャは要らないなんて言わず、DDDを取り入れてみたらどうか と言うことで、インフラストラクチャ層の分離がしっかりしている CleanArchitecture の採用を検

みなさんReactやってますか。やってますよね。最近React Native流行ってるし。 んでいきなりなんですが、あのReactとかいうやつ、実は 特にウェブとは関係ないライブラリ なんですよね。ええぇ……。なのでこの記事ではそれについてだらだらと説明したいと思います。 この記事の背景 最近のReact Nativeブームで「React is 何」「React Nativeについて3行で教えてくれ」みたいなアレコレがよく発生するんですが、その際に「Reactはウェブ向けライブラリである」という先入観がだいぶ素直な理解を阻害しているなーと感じました。 「Reactはウェブ向け」って登場初期は全然間違ってなかったんですけど、厳密には2015年には全く違う状況になって、2019年とか2020年になると完全に間違ってると言える状況が発生し出したので、改めて説明させていただこうと思いました。 別に

ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。 Read less

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

はじめに 今度社内でDDD勉強会をやることになったので、その予習をかねて「エリック・エヴァンスのドメイン駆動設計」の末尾に載っている「用語解説」の中から、最低限これだけは覚えといた方がいいんじゃないかなっていう用語を独断と偏見で抜粋しました。 選定の基準は、 ドメイン駆動設計の理念に関する言葉である 規模にかかわらず有用なデザインパターンである の2点です。 また、括弧内は私の補足です。また引用部分に関しては、読みやすさを考慮して Markdown の引用用シンタックスは使っていません。 1. 概念に関する用語 知識、影響、または活動の領域 (問題領域、業務領域とも訳されます。ソフトウェアが表現する対象。例えば、人事評価システムであれば、従業員や業績が知識であり、目標設定や評価が活動に当たります。影響は何を指しているのか分かりません。たぶん本書にも記載がないです) ドメインエキスパート ソ

This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ

CodeZineにドメイン駆動設計の解説記事がありました。 codezine.jp この連載記事は、書籍化されているそうです。 codezine.jp 「実践ドメイン駆動設計」から学ぶDDDの実装入門 CodeZine Digital First 作者:WINGSプロジェクト 青木淳夫 発売日: 2019/05/31 メディア: Kindle版 この記事を参考にして、ドメイン駆動設計について学んでみたいと思います。

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

CodeZineの人気連載、「IDDD本から理解するドメイン駆動設計」を1冊にまとめました。　DDDとは、「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」です。「DDDという言葉を知っているものの、全容を理解できていない」「どのように開発現場に導入したらよいのか分からない」開発者の方は、意外と多いのではないでしょうか。 図版を多く用い、DDD初心者にも分かりやすく解説した本書は、そんな方にピッタリの1冊です。ぜひ、『実践ドメイン駆動設計』と併せて読んで、理解を深めていただければ幸いです。 以下、本書「はじめに」からの引用です。 2013 年、ヴァーン・ヴァーノン（ 以下Vernon ）氏の書籍『Implementing Domain‑Driven Design』（邦題『実践ドメイン駆動設計－エリック・エヴァンスが確立した理論を実際の設計に応用する』）が

クリーンアーキテクチャ（CA）の本を読みました。 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘 発売日: 2018/08/01 メディア: Kindle版 図の真ん中の「Entities」はドメイン駆動設計（DDD）で作るという話があったので、DDDを勉強してみようと思いました。 ドメイン駆動設計とは？ ドメイン駆動設計の参考書 ドメイン駆動設計の参考記事 関数型プログラミングでのドメイン駆動設計 （via https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html） qiita.com qiita.com nrslib.com CAとDDDの両方を知っておかないと、相違点が分からないです

本書は、初めてDDDを学ぶ方、もしくは実際に着手して「難しい！！」と感じているエンジニアの方を対象とした、ドメイン駆動設計(以下、DDD)についての解説書です。 近年、ソフトウェアのレガシー化が社会的に問題になっていると言われています。 DDDはレガシー化への対策として非常に有用なものですが、日本語で出ている書籍「エリック・エヴァンスのドメイン駆動設計」や「実践ドメイン駆動設計」は非常に重厚かつ難解で、初学者が実用に到達するまでには長い時間と試行錯誤が必要なのが実情です。 そこで本書では、迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、 具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。 また、その後にはレイヤーごとの個別のトピックについて、1章ずつ詳しく解説します。 ■本書の構成 本書は以下の構成になっています。 「第1章 DD

DDD連載記事 なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか ドメイン駆動設計の定義についてEric Evansはなんと言っているのか モデルでドメイン知識を表現するとは何か ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 ドメイン駆動設計について、「どうやって実装するのさ？」の前に、まずは定義について認識合わせをしたいと思います。 背景 「ドメイン駆動設計とは何か？」 ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。 ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。 「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」 ドメイン駆動設計のメリットと始め方(Codezine記事) 「厳しい現実の中で、

ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか？ ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか？ ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか？ それは、

当ブログについて 主にドメイン駆動設計(DDD)関連の情報を発信していきます。 Twitterアカウント @little_hand_s こちらでもDDD情報発信していくのでよろしければフォローお願いします。DDD周りでご質問などあれば気軽にリプライいただければお答えします^^ 人気記事 ドメイン駆動設計解説シリーズ なぜDDD初心者はググり出してすぐに心がくじけてしまうのか 前説みたいな記事です。DDD本読んでよくわからなくてもあなたのせいではないですよ！というメッセージです。笑 ドメイン駆動設計の定義についてEric Evansはなんと言っているのか まずはドメイン駆動設計自体の定義を、公式のドキュメントから確認します。 モデルでドメイン知識を表現するとは何か オススメ!! 実装サンプルでDDDなコードとそうでないコードを比較し、DDDコードの魅力を解説しています。 ドメイン駆動設計で実