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