Rails で DDD をしている時の集約の実装方法を考えます。 ActiveRecord と集約を別として考える メリット 集約が PORO (Plain Old Ruby Object、素の Ruby) で実装できる 集約にDB へのアクセスロジックが混在せず、ビジネスロジックの実装に集中できる デメリット ActiveRecord のインスタンスが別に作成されるのでメモリの使用効率が悪い 集約へ再構成を行う実装コストがかかる (ライブラリがあるかも) 方法 ActiveRecord のインスタンスは DAO として捉えます。 DAO はテーブルに対して操作をおこなうインタフェースとして考えればよく、リポジトリから使用することが想定されます。 例えば、作成や更新を行う リポジトリ#save を実装する場合には以下のようになります。 class UserRepository def sa
Rails でドメイン駆動開発 (DDD) をしたいという時に、考えたディレクトリ構成案です。 開発をしながら改善をして、なるべく Rails と仲良く共存できる形になったのでメモとして残します。 アーキテクチャ オニオンアーキテクチャ 参考: https://qiita.com/little_hand_s/items/2040fba15d90b93fc124 その他前提 複数のコンテキストは含めない なるべく Rails の機能を無効化しない (目標) app/ # いつもの app ディレクトリ ┣ controllers/ # アダプターとしてみなす ┣ models/ # アダプターとしてみなす ┣ mailers/ # アダプターとしてみなす ┣ views/ # アダプターとしてみなす ┣ view_models/ # アダプターとしてみなす ┃ ┣ services/ # ア
「Gherkin」(ガーキン)というプログラムの書き方が紹介されていました。 考え方が良さ気なので、後で調べてみようと思います。(備忘録) gigazine.net ・Gherkinは期待された動作を理解する良い助けになる Gherkinはテストのための記法の1つで、「こういう状態のとき、こういう動作を行えば、こうなることが期待される」という形式で記述していくものです。 ビアソンさんは「たとえ実際にテストでは使わなくとも、Gherkinを書くことでアプリがどういう動作を期待されているのか理解しやすくなる」と述べています。 blog.juliobiason.net ### Gherkin is your friend to understand expectations Gherkin is a test description format which points "Given that
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く