『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。 なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。 DDD本とドメイン駆動設計 DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口に

ddd-in-golang.markdown This is my response to an email asking about Domain-Driven Design in golang project. Thank you for getting in touch. Below you will find my thoughts on how golang works with DDD, changing it. This is merely a perception of how things worked out for us in a single project. That project has a relatively well-known domain. My colleagues on this project are very knowledgeable, t

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 からの連投エントリ。振る舞いとサービス編です。今回もコードを使って解説したいと思います。 サービスとは、モノとして扱うと不自然なものをサービスに分類しようという考えです。 ドメインで扱う概念の中には、1つの機能や処理が単体で存在していて、もの（オブジェクト）として扱うのが不自然なものもある。そうしたものは、サービスという形でユビキタス言語に組み込む。サービスは基本的に状態をもたない（stateless）。 佐藤さんが語られている通りに、従来のサービスとDDDのサービスはレイヤーの位置関係が違います。今までのサービスはDDDのアプリケーション層です。このエントリでは、今までのサービス(DDDのアプリケーション層)の話は一切出てこないので、今までのサービスの概念を一旦忘れましょうｗそう

今回はドメイン開発入門について解説していきたいと思います。 まずはドメイン駆動開発とはどういったものかを述べて、そこから一般的なアーキテクチャとどう異なるかについて説明していきたいと思います。 １． ドメイン駆動設計とは ドメイン駆動設計とは、一言で言うと、ソフトウェアの設計手法のことです。 オブジェクト指向におけるアーキテクチャにおいて、ドメイン層に重点を置いて開発を行い、 仕様が確定したり改修を行っていく度にドメインモデルを反復的に深化させていく手法になります。 ここでのドメイン層とはアプリケーションが対象とする業務領域のことです。 ２． 一般のアーキテクチャとどう異なるか？ まずは一般的なアプリケーション（トランザクションスクリプト）のアーキテクチャについておさらいしてみましょう。 ・プレゼンテーション層 利用ユーザーに対するインターフェースの提供する。 ・ドメイン層（ビジネスレイア

関西DDD.java 勉強会 2016-3-5 (DDD Alliance 勉強会 2016-1-21 @東京の京都再演版）Read less

DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約） FACTORIES（ファクトリ） REPOSITORIES（リポジトリ） 関連 関連をたどる方向を強制する 限定子を付けて多重度を減らす ドメインにとって本質的でない関連を除去する 本質的でない関連が除去された結果、残った関連はそのドメインの特徴を表す E

別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが

論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Gamesatsushi061452

ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく

いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す

Ustream:ワイヤーコミュニケーション 第２回 http://www.ustream.tv/recorded/7738057 Togetter:お気に入り 第2回「ワイヤーフレームコミュニケーション研究会」 - ハッシュタグ " #wireframecomwg " まとめ http://togetter.com/li/30127 「ワイヤーフレームコミュニケーション研究会第2回」のお知らせ http://blog.sinap.jp/2010/05/wireframecomwg02-cm.html

シュキーンの開発とドメイン駆動設計について こんにちわちわ。Underbar.phpの記事ぶりになりました@emonkakです。 本エントリでは、以前のエントリでお伝えした勤怠管理アプリケーションのシュキーンの開発について述べたいと思います。 シュキーンとは シュキーンはAndroidで動作する勤怠管理アプリケーションです。打刻はNFCタグをAndroid端末にかざすことで行います。勤怠データはAndroid端末からサーバーに送信されるので、ネットワーク環境さえあればどこからでも確認することがきます。 開発のスタート 社内向けに使っていたシュキーンを一般公開に向けて改修をするということで、開発はスタートしました。メンバーは私を含む2名で進み、リリース直前に増員があり現在は3名体制になりました。今回リリースされたものは以前のバージョンからほとんど1から書き直すことになりました。 ドメイン駆動

ざっくり Dddをもっと身近に DDDとはこういうことなのか - Some Days You Get the Bear レイヤー化アーキテクチャ ドメイン駆動設計・アプリケーション構築編・レイヤ化アーキテクチャ - Strategic Choice DDDの読書記録（第4章、ドメインを隔離する） - 達人プログラマーを目指して メンタルモデル ドメイン駆動設計を実践するために - Digital Romanticism ドメイン駆動設計・開発の実践 （よく分かんない）

2. エリック・エヴァンスのドメイン駆動設計 エリック・エヴァンス (著), 今関 剛 (監修), 和智 右桂 (翻訳), 牧野 祐子 (翻訳) 出版社： 翔泳社 発売日： 2011/4/9 原書発売日： 2003/8/22 http://www.amazon.co.jp/エリック・エヴァンスのドメイン駆動設計 -IT-Architects’Archive-ソフトウェア開発 の実践-エリック・エヴァンス /dp/4798121967/

2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに