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、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
再考 - ドメインサービス - まっちゅーのチラ裏
自分が大規模システムで組むアーキテクチャは基本的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ
DDD導入に踏み切れない方へ贈る「2層 + CQS アーキテクチャ(Flyweight DDD)」/Flyweight DDD
Flyweight DDD 軽量DDDを避けつつ軽量(Flyweight)にDDDを導入するためのアーキテクチャです。
ドメインモデリングの始め方 - Speaker Deck
ドメイン駆動設計の考え方は書籍を読むとわかりますが、いざモデリングを実践しようとすると、どこから手を付けていいかわからない、ドメインモデリングの始め方がよくわからないという意見を聞きます。 このスライド資料では、そんな悩みを持つ皆さんに向けて「ドメインモデルを見つけ出し・実装に落とし・改善していく」方法を、できるだけわかりやすく解説します。
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
そのトランザクションは果たして本当にトランザクションなのだろうか？ - yoskhdia’s diary
DDDネタです。 DDD Community-JPのDiscordで「複数の集約（Aggregate）をまたいで整合性をどう担保するのが良いのか？」という話がされていました。 この話を読んでいて、 yoskhdia.hatenablog.com でもサラッと触れた「トランザクション」をもう少し掘ってみようかなと思い立ったので書いてみるエントリです。 先の記事では次のように書きました。 実業務、ドメインを見れば、本当にまとめて処理しなきゃいけないものは、結構少ないはずです。 働く人たちは、どういう会話をしているのか、仕事の単位は何なのか、によってトランザクションを設計することが、メッセージングシステムを考えるうえで有用だと考えています。 「トランザクション」という言葉は、開発者にとっていくつかの意味を持ちます。 ここでは、 DB操作のトランザクション（以下、DBトランザクション） 業務のうえ
DDDでエンティティ間の関連を「ロールオブジェクト」でスマートに扱う - Qiita
はじめに 実践ScalaでDDD で発表した中で、エンティティ間の関連を「ロールオブジェクト」として定義する ことをお話ししましたが、スライドでは要約になっています。 実際にプロダクトでやってみて有効なパターンだと感じているので、改めて突っ込んで解説したいと思います。 なお、内容的には Scala をターゲットとしていますが、他の言語にも考え方は応用できると思います。 サマリ DDDで設計していると エンティティ と エンティティ の間に関連があり、その 関連に関するドメインの振る舞い と言うものが出てきます。 例えば 「ユーザー エンティティ」 と 「タスク エンティティ」 がある場合に、その間には 「タスクの作成者」 や 「タスクの担当者」 と言う関連があったりします。 そしてそれらの関連は「タスクの作成者は、タスクを削除する」や「タスクの担当者は、タスクを完了する」のような振る舞いを
日本語のドメイン駆動設計 (Domain-Driven Design - DDD) 関連記事まとめ - なにか作る
ドメイン駆動設計は原典となる「エリック・エヴァンスのドメイン駆動設計」の初版が2003年と歴史があり、モダンなフレームワークであればその思想を取り入れた設計がなされているにも関わらず、日本語の情報が少ない気がする。 最近ドメイン駆動設計をやろうと主にWeb上の情報を探っていたので参考になったサイトをリンク集の形でまとめてみる。 概要 概要を把握するのが一番難しいように思うので、色々と目を通すのがよさそう。 little-hands.hatenablog.com enterprisegeeks.hatenablog.com enterprisegeeks.hatenablog.com speakerdeck.com ドメイン駆動設計とは何か 【入門編】 from 増田 亨 www.slideshare.net 3週連続DDDその1 ドメイン駆動設計の基本を理解する from 増田 亨 www
scala-on-ddd
「2017/9/9 Scala関西Summit 2017」、「2017/10/21 関ジャバ'17 10月度」 、「2018/3/18 Scala Matsuri 2018」でお話した、実践ScalaでDDD の発表資料です。 (English version -> https://speakerdeck.com/crossroad0201/practice-ddd-with-scala-en ) サンプルコードもあわせて参照してください。 https://github.com/crossroad0201/ddd-on-scala 目次 1.DDDとは - DDD - DDDのコンポーネント 2.ScalaとDDD 3.Scala実装スタイル 4.アーキテクチャ - レイヤ構成 - エラー処理 5.コンポーネントの実装 - アプリケーションサービス - エンティティ - バリューオブジェク
practice-DDD-with-Scala_en
The Practice DDD with Scala at Scala Matsuri 2018. (日本語版 -> https://speakerdeck.com/crossroad0201/scala-on-ddd) See sample code on GitHub. (Descriptions are Japanese only) https://github.com/crossroad0201/ddd-on-scala 1. What's DDD? 2. DDD with Scala 3. Code Style 4. Architecture - Layers - Error Handling 5. Implement Components - Application Service - Entity - Value Object - Role - Factory - Repo
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
境界づけられたコンテキストとは 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界づけられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界づけられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界づけられたコンテキスト ・境界づけられたコンテキストをどう実装に
![境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/6bb65ba88fd34a29140629a2f7085b6e005c2663/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171128%2F20171128072027.png)
DDD超入門(後編) - Domain-Driven Designの適用Step - エンタープライズギークス (Enterprise Geeks)
前編ではDDDの概要についてふれたが、後編ではDDDの適用Stepを3つのStepに分けて紹介する。 まずStep1として、アプリケーションに登場しうる概念を抽出してドメインモデルで表現する。 次にStep2として、各ドメインの概念を深掘りしてソフトウェアとしてどう表現するかにについて紹介する。 最後にStep3でドメイン部品の仕上げとDDDの恩恵ついてふれていく。 Step1: ドメインモデルによる表現 DDDでは機能やユースケースに加えて、その裏に潜んでいる「概念」を抽出する必要がある。そのため、DDDを導入するにあたってアプリケーションに登場しうる概念を整理した「ドメインモデル」がまず必要となる。全体のコンテキストを整理して、該当のドメインモデルを描くことがDDDの最初の1歩となる。 例として、よくある一般的な受注管理の簡単なドメインモデルをあげる。 「顧客」からある「商品」の「注文
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
混乱しがちなサービスという概念について - かとじゅんの技術日誌
社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Repositoryによる抽象化の理想と現実/Ideal and reality of abstraction by Repository
集約の設計と実装
Realworld Domain Model on Rails
ドメイン駆動設計基礎講座〜戦略編〜
今日のDDDの重要性についてEric Evans氏に聞く