なぜ自分はDDDを勉強しているのか？
DDDと出会う前 自分は元々アーリーステージ(シード)のスタートアップでRailsを書いていました。人手の問題で拙いながらもReact Nativeでモバイルアプリを作ったりAWSでインフラを構築したりとよくいるエンジニアです。昨年末に今の会社への転職がきっかけでDDDでの開発に従事するようになり独学でキャッチアップしました。元々DDDという単語自体は聞いたことがありました。きっかけは確かこちらの記事だったと思います。 ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ 自分自身Railsを書いてはいましたが、自分のコードに納得感を得られたことは一度もありませんでした。 このロジックはここに書いて良いのだろうか？ DB設計ってこれで合ってるのか？ う〜ん、テストコード書きにくいなあ よくある悩みです。しかし、スタートアップでスピード開発を優先していたの
Railsのアーキテクチャ(Service/Form/DecoratorやDDD)について考えるための読み物まとめ - Qiita
原典 7 Patterns to Refactor Fat ActiveRecord Models 肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳） FatModelをリファクタリングするパターンを示し、議論の先駆けとなった記事の模様。 Service/Form/Decoratorについて Service 自分的解説 以下のいずれかとして利用されるように思われる。 ユースケースごとに複数のコンテキスト(ユーザーの更新とメールの送信など)を組み合わせて記述するレイヤー。（= アプリケーションサービス） または モデルに実装すると不自然なドメインロジック(複数のオブジェクトを組み合わせて表現するロジックなど)を記述するレイヤー。（= ドメインサービス） パーフェクトRails増補改訂版ではこちら。 参考記事 似非サービスクラスの殺し方 / #ginzarb Ra
2021-07-12 Rails composed_of を使ったValue Object パターン
2021-07-12 Rails composed_of を使ったValue Object パターン 12 July 2021 (Updated on 08 Jun 2022) Rails で Value Object パターンを扱うのに便利な composed_ofについて調べた。 オプション class_name: Value Objectの名前。Value Object生成時にこのクラスが使われる mapping: ActiveRecord Object <=> Value Object の相互変換に使われるattributeのマッピング。複数の値をValue Objectに展開する場合 Array of Arrayの形式でここを渡す constructor: ActiveRecord Object => Value Object に展開するときのメソッド converter: Se
composed_of を使って Rails で値オブジェクトを扱う - Sansan Tech Blog
DSOC サービス開発部でエンジニアをしている石畑です。普段は Rails で名寄せサービスを作っています。 今回は Rails で値オブジェクトを扱うのに ActiveRecord の composed_of が便利なので、紹介します。 値オブジェクト 値オブジェクトは DDD でも紹介されている概念です。多くのわかりやすい解説が世の中にあるので、詳しくは検索してもらえればと思いますが、ものすごく大雑把に説明すると「各属性で等価を判断できる不変なオブジェクト」です。 例えば「とあるスーパーでお肉を売る」を考えたときに、最初「300 円」で売っていた「お肉 A」を途中タイムセールで 100 円引きの「200 円」で売ったとしても「お肉 A」は値段を変更する前と「同一のお肉」です。 お肉のセール そのため、「お肉」の同一性は属性で判断することはできず、バーコードのような識別子で同一性を追跡し
Railsの利点と欠点、RailsがDDDや大規模開発に向いていない理由 - Funna(ふんな)の技術ブログ
知り合いが「Railsの長所ってなんやっけ？」って話をしてたので、その辺のRailsの長所・短所とか、RailsがDDDや大規模開発に向いてない理由を自分なりに整理してみた。 間違っている点などあれば是非ご指摘頂きたいです。 ※2023/07/21 追記: 本記事においてユースケースという言葉を多用していますが、文脈（コンテキスト）という言葉を使用すべきだったかもしれません🙏 DDDにおいてモデルはユースケースごとに分かれるのではなく文脈ごとに分かれるものであり、本記事でも文脈というニュアンスでユースケースという言葉を使用していましたが、適切な言葉を選ぶべきでした。 ex. 商品というモデルを販売コンテキスト、配送コンテキストに分ける（参考: 境界づけられたコンテキスト 概念編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab）。 Rails（Active
RailsでDDD 2020-2021 - Qiita
5年前に書いたこの記事をいまだにストックしてもらうことがあるのですが、別のアプローチでRailsによる戦術的DDDを実装しているので軽く紹介します。 ※太字は戦術的DDDパターン名 Githubリポジトリ haazime/fridge 変わってないところ アーキテクチャスタイル appディレクトリと同じ階層にdomainディレクトリがある domain内はMODULES単位になっている 永続化はActiveRecordで行われる 変わったところ ドメインモデルとコードの整合性を保つ ドメインモデルを表す図などとコードを一致させ、その状態を保ちます。 コードを書いてみて違和感があればそれをドメインモデルに反映します。 MODEL EXPLORATION Whirlpool - CODE PROVE domainはRailsに依存していない 次の永続化にも関わりますが、domainディレクトリ
RailsでDDD - Qiita
別のアプローチによる実装の記事を書きました。 よろしければこちらもご覧ください。 「かんばん」を、DDDで設計しRailsで実装してみました。 kanban_core_extension 現時点では、最小限の機能しかありませんが ドメイン駆動設計をRailsで実装する際の一例として参考になれば幸いです。 アプリケーションの機能 開発するフィーチャ（タスク）をカードで表現し、進捗状況をかんばんボードで可視化する カードを次のフェーズ（進捗の区切り）に進める時にWIP制限をチェックする アーキテクチャスタイル Event SourcingなしのCQRSです。 変更（Command）の時だけドメインモデルを使います。 問い合わせ（Query）では、必要なデータをデータベースから直接取得します。 リポジトリからドメインモデルを取得することはしません。 取得したデータは構造化されたオブジェクトですが
ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！ - Qiita
この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ
Railsにおけるドメイン駆動設計の実践
「RailsでDDDをするのは難しい」とよく言われるが、こういう方法もあるというのを提示する。 ある程度のRailsの経験、エヴァンス本とPofEAAを十分に理解していること、ソフトウェアアーキテクトとして弁えるべきことを弁えていればこのページに書かれていることは納得いただけると思う。 DDDを実践するということ 本題に入る前に断りを入れておきたいが、DDDをするということは要求分析やモデリングをきちんと行うということを意味する。「ドメイン」という言葉も「モデル」という言葉も要求分析の文脈の言葉であるし、どんな分析手法を取るにせよドメインエキスパートと会話しながら分析を行わなければドメインモデルを明らかにすることはできない。 無論、数百ページに及ぶ要件定義書を書けという話ではない。スクラムで言えばスプリントバックログに入れる前にフィーチャーのモデリングは終わらせておけというだけの話である。
「RubyでDDDやるならHanami」という噂の真相
こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。 InnoScouterでは、Ruby製WebフレームワークであるHanamiを採用しており、DDDを用いて開発しています。 Hanamiについて言うと、私個人としては、前職も含めて4年ほど運用経験があります。 ここでは、Hanamiが出てくるとよく話題にされるRailsとの比較は取り扱いませんが、初めてHanamiについての記事を読まれる方にも分かるようなサンプルコードで説明したいと思います。 突然ですが、こちらが本日のメイントピックです。 今回は、「RubyでDDDやるならHanami」と言われてますが、本当にそうなの？ってところを掘り下げていきたいと思います。 ツイートが意味していることと、それに対する自分の考えを話していけたらと思います。 この記事の対象読者 Rubyを触
ValueObjectという考え方 - Qiita
以前、DDD（ドメイン駆動開発）を経験した流れでいくつかのことを学びました その中でDDDの神髄を垣間見たのでかいつまんで紹介できればと思います 記事のターゲット DDDを学び始めた人 値オブジェクト・ValueObjectとはなにか、その片鱗を知りたい人 Value Objectとは 値オブジェクトとしてエリック本(青本)では紹介していますね Value Objectの特徴 特徴として以下のような内容があります 一意性を持たない 計測／定量化／説明を責務とする イミュータブルオブジェクト 交換可能 ふるまいに副作用がない 一意性を持たない オブジェクト毎に hogehoge_id のような一意性を表現するプロパティを含まず、一意性がない特徴です 逆にIDを持つようなオブジェクトは「Entity」といいます この特徴の意味するところはオブジェクトをプリミティブライクに扱えることだと考えられ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
composed_of | Railsドキュメント
Railsで考えるドメイン駆動設計のコアドメイン