Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
ドメイン駆動設計に１５年取り組んでわかったこと
Aws Dev Day2021 「ドメイン駆動設計のマイクロサービスへの活用とデベロッパーに求められるスキル」参考資料(松岡パート)
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
これならできる！ドメイン駆動設計に役立つイベントストーミング - Qiita
はじめに コンテナ技術の進展に伴って、ビジネス環境の変化に迅速に対応できるマイクロサービスに関心が集まっています。最近では、マイクロサービスを分割する方法の一つとしてドメイン駆動設計が注目されています。ドメイン駆動設計では、業務に精通した方々や技術者が、モデリングなどいろいろな技法や専門用語を使い、それらを理解した上で設計を進めていきます。様々なステークホルダーとチームを組んで一緒に取り組むにしても、直観的にはとてもわかりづらいと感じています。そこで、いろいろと記事を調べてみたり、身近な技術者と意見交換をしたところ、イベントストーミングという手法がありました。イベントストーミングに関する記事は他の記事に比べあまり多くはないので、この場で共有しておきたいと思い掲載することにしました。これからドメイン駆動設計をはじめるという方や、既に取り組んでいるけれど進め方に悩んでいる方など、参考になれば幸
経験者がいない状態で、戦略的DDDを現場でやってみた話/ OOC2020
OOC2020での登壇用資料です。 プロポーザルは以下リンクから。 https://fortee.jp/object-oriented-conference-2020/proposal/68aed814-c5b4-4662-bcc3-40345ad09612
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか - little hands' lab
Object-Oriented Conference 2020で登壇させていただきました。 その際の発表資料です。 発表資料 DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか from Koichiro Matsuoka www.slideshare.net 本章の内容は技術書典8(2020/3/1)で頒布予定の「ドメイン駆動設計 モデリング/実装ガイド」の1,2章の内容になります。 全部で11章仕立てです、興味お持ちいただけたらお買い求めください。 受け取りは技術書典以降になりますが、それでもよろしければboothで予約可能です。 little-hands.booth.pm また、実践にあたって頻出の疑問に対してトピックごとに詳しく解説した書籍もあります。 重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具
わかった気になるDDD入門記事まとめ - Qiita
はじめに こんにちは。はじめまして。tarokamikazeです。 これは、社内勉強会用に参考資料をまとめたものです。 この資料のゴール DDD専門用語について、どんなワードでググったらいいかわかるようになる DDDを知らない人が、戦術的DDD(軽量DDD)だけでもやってみようかなという気になる 前段; MVCの限界 余談ですが、凝集度・結合度の観点からするとRailsのMVCがどう問題があるかをコラムで紹介しています。MVCそれぞれの責務を図示すると、低凝集・高結合になっていることがわかります。 とにかく、凝集度、凝集度なのです。 pic.twitter.com/fDWv1ERJA1 — 松岡@技術書典8Day2え28 / DDDブログ書いてます (@little_hand_s) February 2, 2020 あえて過激に言うと。 ある程度の複雑度を持ったアプリケーションにおいて、M
軽量DDDは有りか？ - Qiita
その他のキーワードとして クリーンアーキテクチャ オニオンアーキテクチャ オブジェクト指向 トランザクションスクリプト 実際、軽量DDDは有りだと思うかどうか？ 有りだと思っている。値とロジックを一緒にしておくことでオブジェクト指向的になり、コードは整理される。 DDDとオブジェクト指向の違いは？ DDDもオブジェクト指向の一種ではないか。DDDはその中でもドメイン部分に注力する。 そのせいかファイルの入出力などはトランザクションスクリプト的な書き方になりがち...。 クリーンアーキテクチャやオニオンアーキテクチャを適用しないとDDDにならないか？ アーキテクチャとDDDは切り離して考えられる。 違うアーキテクチャを採用してもDDDをすることは可能。 軽量DDDから重量（？）DDDに移行できるのか？そもそも境界線は？ コアドメインやサブドメインを意識してクラスを考え始めたらちゃんとしたDD
何がDDDをDDDにするのか / what make DDD to DDD ?
DDDを学習・実践において多く見受けられる混乱と、それに対する現時点での自分の回答
【DDD練習】「JR 新幹線 料金ルールを実装してみよう」にチャレンジ（その１） - shimapapa.io
前置き 『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法』の著者の増田さんが、 ワークショップで使用する「JR 新幹線 料金ルールを実装してみよう」というサンプルコードをGitHubで公開されておりました。 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 作者:増田 亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: Kindle版 明日 12/14 の「現場でDDD ! 2nd」のワークショップで使う、サンプルコードです。 新幹線の運賃と特急料金の計算ルールを、値オブジェクトで表現してみよう、という内容。 イベントに参加されない方も、ぜひ、チャレンジしてみてください。https://t.co/LlLKA5h7Bt #genbadeDDD— 増田 亨． (@masuda220) 2019年12月13日
solid+cqs+dry
Kubernetesって何？ -大規模なKubernetesを運用するKubernetes as a Serviceチームの話を添えて-
TypeScriptでの値オブジェクトとフロントエンド・バリデーション - Qiita
この記事はトレタ Advent Calendar 2019の5日目です。 こんにちは、奥野賢太郎 ( @okunokentaro ) です。私は株式会社トレタの社員ではなく、フリーランスのデベロッパーなのですが、今年一年トレタ社のお仕事のお手伝いをさせていただいて、縁がありましてゲスト寄稿的にカレンダーに参加しています。 要約 トレタ社では様々な種類の入力フォームを備えたアプリケーションを運用しています バリデーション処理の分散は修正漏れやバグに直結するので、共通化しましょう 単なる共通化では問題があるため、値オブジェクトに集約しましょう TypeScriptでの値オブジェクトの定義には一工夫が必要です constructor validationの手法を紹介します なにをやっているの？ 私はTypeScriptやJavaScriptを専門としたデベロッパーなので、主にフロントエンドや、場
DDDの勉強にオススメ！な書籍とブログを聞いてきた@「レガシーをぶっつぶせ。現場でDDD！2nd 」参加レポート - omuriceman's blog
2019年12月14日に開催された「レガシーをぶっつぶせ。現場でDDD！ 」に参加してきました。今回で2回目の開催になるそうです。テーマが「インプット<アウトプット」と言うことで、ハンズオンが多めでした。 genbade-ddd.connpass.com 少し遅くなりましたが参加レポートとセミナー中に話題に上がったDDDの学習コンテンツをまとめましたので皆様のお役に少しでも立てれば幸いです。 イベント開催の経緯 ①モデル・コードの変更が互いにどう表現されるか体験するためのハンズオン ②ドメイン駆動設計の基本スキルを体験的に学ぶ～値オブジェクトの見つけ方・作り方・育て方 DDD(ドメイン駆動設計)の学習を始めるには 📚書籍 ✏️ブログ まとめ 備考 グラフィックレコーディング BIGLOBEさんハンズオンの各チームのモデリング イベント開催の経緯 イベントの冒頭に本イベントの開催経緯につい
ドメイン駆動設計に出てくる概念モデルと分析モデルの違い - プログラマの思索
ドメイン駆動設計に出てくる概念モデルと分析モデルの違いについて、良い記事があったのでメモ。 【元ネタ】 ドメイン・フレームワークのススメ(第1回) ドメイン・フレームワークのススメ(第2回) 【1】概念モデル、分析モデル、設計モデルを以下で定義している。 これは分かりやすい。 (引用開始) 概念モデル：問題領域に対する「理解のしやすさ」を重視したモデル。 実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。 分析モデル：概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。 設計モデル：分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。 (引用終了) ドメイン・フレームワークのススメ(第1回)では、G
設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
関数型言語で DDD - Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# - Shin x Blog
オブジェクト指向言語でドメインモデルを実装することが当然のように行われていますが、Go で開発したり、Haskell で遊んだりしている中で、他のパラダイムの言語で実装するのはどうなんだろうかという想いがありました。 そんな時に出会ったのが、Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# という本です。 概要 構成 ドメインを理解し、モデリングする 端的なフレーズ Database-Drive-Design や Class-Driven-Design との違い 型、型、型 関数型言語による実用例 恐怖のモナド さいごに 参考 概要 本書は、とある会社の受注とその関連業務をドメインとし、モデリングして、実装していくという内容です。紙ベースで行われている業務
#チケット料金モデリング でDDD+Clean Architectureする - Qiita
漢なら黙ってコードホトトギス TL; DR. 世は戦乱。 #チケット料金モデリング というハッシュタグにてアプリケーション設計を営みとする猛者たちに火蓋が切り落とされました。ワイも参戦すべく張り切っていったのですが、女子高生の無駄遣いを見たり女子高生の無駄遣いを見たり、女子高生の無駄遣いを見たり、iPad Proを買いに行っていたら2週間くらい経っていました。 さすがにこれでちょっとしたコードを晒すだけなのはアレなので、どうせならドメインモデリングだけにとどまらず、簡単なcliっぽい形にしてクリーンアーキテクチャを実現してみることにしました。言うならば 実践クリーンアーキテクチャチケット料金モデリングといったところでしょうか(ただ単に大きな話題に乗っかっただけともいう)。お題を提供してもらったかとじゅんさんに多謝です。 github repository サンプルコードだけ先に見せろよ、ま
ドメインロジックはドメインオブジェクトに凝集させる - Qiita
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください！ コード例はScalaですが難しい表現がないので、Scalaが分からな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Object-Oriented Conference] 資料まとめ | Qrunch（クランチ）![[Object-Oriented Conference] 資料まとめ | Qrunch（クランチ）](https://cdn-ak-scissors.b.st-hatena.com/image/square/0f64a6c7820c903910c22e636de97c682a084858/height=288;version=1;width=512/https%3A%2F%2Fs3.qrunch.io%2FJLOPGfOJHRrDqcr3EFRU0FqLMbbhDKGl.png)
GitHub - masuda220/business-logic-patterns: experiments for business logic patterns
GitHub - hiroaki-suzuki/ticket-price-modeling-challenge