DDD: ImmutableなEntityの実装方法〜ステートソーシングなEntityとイベントソーシングなEntity〜 - Qiita
DDD: ImmutableなEntityの実装方法〜ステートソーシングなEntityとイベントソーシングなEntity〜ScalaDDDドメイン駆動設計 ドメイン駆動設計では、Value ObjectはImmutable、EntityはMutableという雰囲気があるように思うが、ScalaでDDDを実践しようとなると、EntityがMutableでは逆に実装が複雑になることが多い。僕がDDDを始めた2013年頃は、ImmutableなEntityの実装に関する情報がほとんどなく実装方法を試行錯誤していた。その中で、個人的にImmutable Entityの実装方法が落ち着いてきたので、僕がどのように実装しているかについて紹介したい。 なお、ここで紹介するScalaコードはGitHubのsuin/scala-playgroundで公開しているので、コンパイル・実行など試してみたい場合はご
ドメイン駆動設計でビジネスを駆動する
ソフトウエア開発者はコードの設計と維持だけでなく、その経験を生かしてビジネスサイドに方向を与える能力も持ちつつある。ドメイン駆動設計(DDD)を使うことで、開発者は顧客の振る舞いを見つけビジネスの性質を変化させるための施策を推奨できる。 Jef Claes氏(http://jefclaes.be)はオフショアの開発者によって作られたアプリケーションを自分たちのチームで管理、拡張しやすいようにリファクタリングする仕事をした。新しいリファクタリングされたアプリケーションはオンラインギャンブルという氏の会社のビジネスのニーズにより整合的ではならない。氏はリファクタリングにDDDの方法論を導入した。集約、エンティティ、値オブジェクトを作り、状態の仕組みとしてイベントソーシングを採用した。結果、システムはビジネスの施策と会社の文化に変化を起こすような顧客の振る舞いを見つけたのだった。 InfoQは氏
3週連続DDDその1 ドメイン駆動設計の基本を理解する
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Gamesatsushi061452
「実践ドメイン駆動設計」社内読書会まとめ ～IDDD本難民に捧げる1章から7章～
関西DDD.java 勉強会 2016-3-5 (DDD Alliance 勉強会 2016-1-21 @東京の京都再演版）
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 Domain-Driven Design ( DDD ) 準備 ／ スタートアップ ／ ブラッシュアップ ／ チャレンジ ／ 参考書籍 ／ Read less
レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記
自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
DDDのドメインイベントについて勉強 - Mitsuyuki.Shiiba
DomainEvent ドメインエキスパートが「…した『とき』に、こうなる。」とか。 何かの状態変更をトリガーにして、別の処理をしたい場合にドメインイベントを使う。 イベントオブジェクトがイベントの情報を運んでくれる。 source data & processing data Domain Event ドメインイベントはイミュータブルな「source data」とミュータブルな「processing data」で構成される。 source dataってのは「イベントが発生した」という部分の情報で、これは一旦作成されたら変更されることはないよね。 processing dataは「システムがこのイベントをどうしたか」って情報ね。分けてもいいかもね。 Aggregate & DomainEvent DDDでは、1つのユースケース(トランザクション)で触ってイイ集約は1個だけ。なんだよね。 だ
戦術的DDD基本原則まとめ - Qiita
DDDを実践し始めてまだ日が浅いので、ドメインモデリング中に 細かい原則がすぐ出てこなくて迷うことがあります。 そこで、「エリック・エヴァンスのドメイン駆動設計」から 第2部「モデル駆動設計の構成要素」を中心に、モデルを表現する各要素（パターン）の 基本原則をまとめてみます。 第5章「ソフトウェアで表現されたモデル」 関連 ENTITIES（エンティティ） VALUE OBJECTS（値オブジェクト） SERVICES（サービス） MODULES（モジュール） 第6章「ドメインオブジェクトのライフサイクル」 AGGREGATES（集約） FACTORIES（ファクトリ） REPOSITORIES（リポジトリ） 関連 関連をたどる方向を強制する 限定子を付けて多重度を減らす ドメインにとって本質的でない関連を除去する 本質的でない関連が除去された結果、残った関連はそのドメインの特徴を表す E
DDD本読了記念：独りDDDにトライしてみてる - 冥冥乃志
コップ本といい、DDD本といい、最近鈍器系の本づいてます。仕事のピークが重なっていたので、会社の行き帰りの電車の中か昼休みにしか読む時間が取れず、読み切るまでに非常に時間がかかってしまいました(3ヶ月以上かな？)。 副題にある通り、開発者がユーザとともに複雑さに対峙するための方法を(問題を切り分けよう、とかそういうお題目レベルではなく)実際の設計プロセスやパターンにまで落とし込んでいて、実践的であり具体的です。パターンそのもの以外にも、著者の経験に基づく設計現場のサンプル(開発者とユーザの対話とそれに伴うモデルの変化)が豊富で、パターンだけだとわかりづらくなる箇所を捕捉してくれています*1。しかも、理論ばかりの設計方式ではなく、ちゃんと実装とビジネスをモデルでつなぐための方法であるというのもすばらしいです。ってか、技術を知らずに設計ができると思っているご用聞きSEさんは遠慮なく死んで下さい
InfoQ: コンテキストマッピングによる戦略的ドメイン駆動設計
図１．ユビキタス言語はモデルを表現するのに用いられる唯一の言語でなければならない。チーム内のメンバは誰もが、個別の各用語についてあいまいさの残らない形で合意せねばならず、翻訳する必要がないようにしなければならない。 コードはモデルを表現する主要な形態です。要件なり設計の一部分をとらえる過程においては、それ以外の成果物も必要になるかもしれません。しかし、アプリケーションのふるまいと恒常的に同期しているのはコードそれ自体なのです。このようなモデリングの理想郷は、いくぶん脆弱なエコシステムです。前述したような条件が与えられれば実現は可能ですが、むやみに拡大することはできません。概念的統一性を妥協することなく、モデルを拡大することができる最大の範囲が、コンテキスト（"context"）と呼ばれています。 境界つきコンテキストに踏み込む ドメイン駆動設計において、コンテキストは次のように定義されてい
大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる
ドメイン駆動設計の道標 - sandbox
この記事は 2016年 第2のドワンゴアドベントカレンダー、20日目の記事です。 qiita.com ドメイン駆動設計に関して悩める若者に送るポエムを書いていたら長くなりました。 20日目なはずなのに今日は 12/25 ですが、お察しください。 TL;DR ドメイン駆動設計には3つの顏がある それは「哲学」「戦略」「戦術」である 「戦術」にスポットがあたりがちだが、まず「哲学」とコアの「戦略」から理解する プロダクトにおけるドメインモデルの全体像を描いてから「戦術」を検討しよう ドメイン駆動設計をどの程度取り入れるかの 「ドメイン駆動設計の適用レベル」について はじめに ドメイン駆動設計(DDD)、以前と比較して認知が上がってきたのか、よく「DDD やってるんですか?」 「DDD ってどうはじめればいいんですか?」と聞かれることがあります。そしてこの時にまず話に上がるのが、エンティティ、集
ドメイン駆動設計を取り入れてみて感じたこと。 | FiNC Developers Blog
ドメイン駆動設計を取り入れてみて感じたこと。 はじめまして、FiNCのWeb Applicationエンジニアの重村です。 ウェルネスサーベイというサービスを作っています。 FiNCではマイクロサービスと呼ばれるアーキテクチャパターンを積極的に採用しており、十数個のサービスがあります。 私が担当している「ウェルネスサーベイ」は、FiNCが提供している主軸サービスに導入されている重要なサービスになっており、使いやすい機能やわかりやすいデザインを考えるだけでなく、良い設計や保守性の高いコードを書くことを求められます。 そこで私はドメイン駆動設計という良いコードを書くためのノウハウを、このプロジェクトに取り入れようとしてきました。 今回は、プロジェクトに取り入れたドメイン駆動設計の5つの方法と、それらに対して感じたことを紹介したいと思います。 ドメイン駆動設計の知識や考え方ついては、以下の資料に
20151110 ドメイン駆動設計によるサービス開発
ビッグローブでDDDを導入して早２年。 この２年間、ISP事業における主要なサービスをDDDで開発してきて、試行錯誤の連続でした。 今回は、試行錯誤の過程を経て生まれた、実際に実践している ・設計・実装の考え方（ドメインモデルやコード例やDB設計など） ・チーム環境の考え方（開発プロセスやチームビルディングなど） の２つを軸に現場でのリアルな体験を紹介します。 また、最後に、試行錯誤における失敗談も紹介します。 Read less
「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
FluxとDDD(レイヤードアーキテクチャ)について考えてみた - embryo
トレタ Advent Calendar 2016 - Qiita 16日目の記事になります。 フロントエンドエンジニアのすえだです。 はじめに Flux実装する上で曖昧性をできるだけ無くすために頑張る話です。 ***アーキテクチャはこうあるべきみたいな原理主義的な話はありません。あくまで参考です。 この記事で書いていること Fluxについて DDD(レイヤードアーキテクチャ)について FluxとDDDの関係性 Fluxのレイヤー化 Fluxについて 単方向に伝搬されるデータでアプリケーションの状態を表現するアーキテクチャパターンです。 CQRSとEvent Sourcingを組み合わせたような形になります。 恩恵 単方向のデータフローにより、行ったり来たりのような処理が少なく振る舞いを理解しやすい DispatcherやActionがシングルトンで表現されるので参照に悩まされづらい DDD
クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita
SPA、スマートフォンアプリの隆盛。時代はクライアントサイドに主権が移ってきている。 これからの時代はクライアントサイドにロジックを持たねばならぬだろう。 一方サーバーは、「ユーザー１人でも完結するサービス」に限れば、 DOA(Data Oriented Architecture)的な立ち位置のもの(≒mBaaSとか)と、BFF(Backend for Frontend)的な立ち位置のものがあればよくなる。 モデル定義がダブる いままでモデルはサーバーのものだった。 クライアントでは「JSON」というデータになってやってきて、 それをなんとなく成形して表示してた。 でも来るべきクライアント主権時代においては、 やっぱりクライアントでもJSONじゃなくてドメインモデルを扱いたい。 そうするとサーバー/クライアントの2つの環境でモデル定義を書かなくてはならないではないか。 多くのサービスは実は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リアクティブDDD
ドメイン駆動設計を軽快に実践するための工夫
