ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
CQRS実践入門 [ドメイン駆動設計] - little hands' lab
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
![CQRS実践入門 [ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/c1461d1de08cfc1309c0a0f3c18a2f498485bb45/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1a101957924fd716c353278f0d65759b39326613%2Fbackend%3Dimagemagick%3Bheight%3D1200%3Bversion%3D1%3Bwidth%3D1200%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20191202%252F20191202061944.png)
設計要件をギッチギチに詰めた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] - little hands' lab
DDDの文脈の中で、 「ドメイン知識とユースケース(≒アプリケーションの知識)は何が違うのか？」 という疑問がよく持たれます。 この記事ではその違いを説明し、DDDのコードにどう反映するかを書きます。 あるToDoアプリの仕様 事例として、ToDoアプリの話をします。 「仕様を決める」と言ったとき、以下のように箇条書きで決めることがあると思います。(Jiraのようなチケット管理システムのチケット詳細として書いたりしますよね) ユーザー登録、非活性化ができる メールアドレスは重複登録できない タスク登録、更新、完了、未完了に戻す、延期、ユーザーへのアサインができる タスクは3回までしか延期ができない 非活性化されていないユーザーにアサインができる タスクを完了、アサインするとタスクレポートが作成される これはいわゆる「ビジネスロジック」と呼ばれて、3層レイヤーのアーキテクチャではBusine
![ドメイン知識とユースケースの違いは何か？[ドメイン駆動設計][DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/0875f8b3178c00cab1fef1b61aa8b0ce19d6e550/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F1e681bbb59c1d58f3d7c4c14af30922252cdc250%2Fbackend%3Dimagemagick%3Bheight%3D1300%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fl%252Flittle_hands%252F20190726%252F20190726071431.png)
Java と Spring Boot でドメイン駆動開発 〜レイヤーとモジュール分割編〜 - Qiita
ドメイン駆動開発について ドメイン駆動開発はその名の通り、単なる実装パターンではなく開発要員以外のメンバーをも巻き込んだ開発手法である。 なぜ 3 層に分割するのか ドメイン駆動開発の設計では以下の 3 層に分けてソフトウェアを設計せよとされている。 アプリケーション層 ドメイン層 インフラ層 なぜこのような分割をするのか。突然モバイルアプリ版の開発が始まるかもしれないし、突然 DB が RDB ではなくなるかもしれないからである。 そのような場合に同じドメインのソフトウェア間で再利用できるものがドメイン知識であり、これを含んだものがドメイン層にあたる。 アプリケーション層 メイン関数 アプリケーションサービス (セッション管理など) コントローラー ビュー, メールのテンプレートなどのプレゼンテーション ビュー用の値オブジェクト, DPO ドメイン層 ドメインサービス エンティティ 値オ
値オブジェクトの実装 - .NET
このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。 これまでのエンティティと集計に関するセクションで説明したように、ID はエンティティの基礎です。 一方、システムには、ID と ID の追跡を必要としないオブジェクトとデータ項目が多数あります。たとえば、値オブジェクトなどです。 値オブジェクトは他のエンティティを参照できます。 たとえば、あるポイントから別のポイントに到達する方法を示すルートを生成するアプリケーションの場合、そのルートが値オブジェクトです。 これは特定のルート上にあるポイントのスナップショットですが、内部的には City、Road などのエンティティを参照していても、この提案され
途中から始めてるDDD - KAYAC engineers' blog
Lobi事業部の長田です。 Tech KAYAC Advevtent Calendar 2018、17日目の記事です。 TL;DR DDDを実践して半年ほど コンテキスト分割して実験できる環境を作るのは良い 自分たちが何を作っているのかを考える必要があるのは良い イニシャルコストと開発工数の増加は避けられない どこで始めているのか カヤックにはLobiという2010年から運用を続けているサービスがあります。 https://web.lobi.co 運用期間が長いシステムによくある悩みとして、 経年劣化で様々な箇所で問題が発生しつつあります。 その中でもソースコードの問題として、 締切に追われて書いた！動いた！のはいいものの、その後リファクタリングされなかったコード 提供終了したにもかかわらず、削除されていないコード 肥大化したUserモジュール などなど、該当箇所を触るたびにつらい思いをす
ドメイン駆動設計なエンジニアの育成プログラムを作った - なおしむ論
この記事は Engineering Manager vol.2 Advent Calendar 2018 - Qiita の16日目の記事です。 今の会社にはチームにジョインした方に対してドメイン駆動設計での開発ができるように育成するプログラムがあります。 「プログラムがある」と言っても有志で持ち回りでやってるちょっと真面目な勉強会のようなものです。 それを私がやることになったので、今日はその時に考えたことを書きます。 身の回りに勉強会等開いてくれる人がいたら「あの人はこんな感じのことを考えてるのかー」と思ってもらえたら幸いです。 誰？ 名前: なおしむ 某ISPでエンジニアをしている 最近は新しく来た人の育成もしている 背景 現在のプロジェクトはビジネスの特性上、市場変化に対応しつつバグのない開発が求められている そのために内製 + ドメイン駆動設計(DDD)で開発している リンクいろい
ドメイン駆動設計 - ドメイン駆動設計のエンティティにgetterは必須でしょうか - スタック・オーバーフロー
getterは必須ではありません。 ちょっと手間ですが、私は「リポジトリでカプセル化を破るためのインタフェース」を使うことがよくあります。 ※多分何かのデザインパターンとして名前があったと思いますが、分からないです PHPが分からないのでJavaで書きます。 // Hogeエンティティ // ドメインモデルなので当然ドメインレイヤーに配置 public class Hoge { // IDはずっと変化しない // ドメイン上ではgetterが不要だが、永続化の際に取り出せる必要がある private final int id; // 名前は変更することがある private String name; public Hoge(int id, String name) { this.id = id; this.name = name; } public String name() { retu
実践DDD本 第12章「リポジトリ」～集約の永続化管理を担当～
実践DDD本 第11章「ファクトリ」～複雑な生成をユビキタス言語でシンプルに～ リポジトリとは 一般的に「リポジトリ」とはデータの「保管庫」を表します。ソースコードリポジトリであればGitやApache Subversionが有名ですが、DDDにおけるリポジトリは、エンティティや値オブジェクトから構成される集約の格納と取得を担当します。リポジトリは、クライアントへ集約を提供し、背後のデータベースとのやり取りを隠ぺいします。 通常、集約とリポジトリの関係は一対一になります。例えば「注文」の集約を利用したい場合「注文リポジトリ」を使用します。クライアント側はリポジトリのおかげで、物理的な構成（RDBなのか、NoSQLなのか等）を意識せずに、簡単に集約を操作できます。 リポジトリで集約を操作する流れ リポジトリはデータベースにアクセスしたり、ファクトリを利用したりします。その流れを見てみましょう
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
松岡@ログラス/DDD,アジャイル on Twitter: "なお、EntityとValueObjectの区別としては、不変性よりも一位に識別したいかどうかの方が重要です。 一意に識別したいが、不変である、というEntityがあることはおかしくありません。 また、一意な識別子は必ずしもIDである必要はありませんし、1つの項目とも限りません。"
複雑なドメインに泥臭く立ち向かう - Speaker Deck
Scala でつくる証券会社とスタートアップ / Securities and Startup with Scala - Speaker Deck
かとじゅんさんのツイート: "「薄い本を教えてほしい」ということですが、以下の本がちょうどよいと思います！ #AWSDevDay Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 https://t.co/VcCz94T8ce わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～【C91新刊】 https://t.co/Ci23VCS9ok… https://t.co/B6QDteVGht"
たなかこういち on Twitter: "App層は機能要件を普通に実装すればよいが、 Domain層は、コンテキスト全域におけるDbCの事前・事後・不変条件を死守する振る舞いを実装するのだ。「それをやられちゃデータの一貫性が破壊されるのでこれだけは守ってくれ。その範囲で何やっても良い」と実装するのだ。"
松岡@ログラス/DDD,アジャイル on Twitter: "DDDモデリングの進め方仮説 ・スコープをまずは小さく切る ・モデリングに当たってドメインエキスパートと会話できるようにする ・ユースケース図を作ってアクターを明示し、スコープを切る ・ドメインモデル(クラス図の簡易版)と、モデル… https://t.co/zLqWoJ9sZC"
増田 亨． on Twitter: "画面用にはViewModelオブジェクトとViewModelFactory(メソッドまたはクラス)をプレゼンテーション層に用意する。 Requestも、内容によっては、いくつかの計算Aggregateへの分解をプレゼンテーション層… https://t.co/6RLKXyVdBA"
松岡@ログラス/DDD,アジャイル on Twitter: "jooqでDDDのreposistory、全然いけそう。 jooq、MySqlのonDuplicateKeyUpdateが対応してるので、repositoryでinsertOrUpdateの処理を書くのも簡単にいけそう。hiber… https://t.co/NBzUssymsw"
http://stg-tud.github.io/eise/WS11-EiSE-07-Domain_Modeling.pdf