はじめに 夏なのに家で冷房を入れることを禁止されているどうも鈴木です。まさに地獄です。 さて、コントーラーやモデルが肥大化する話はRailsを普通に使っていると誰しもが直面する話だと思われます。 例えばUserモデルのように、色々なところから参照されるモデルは地獄みたいなことになってしまいます。地獄は家だけにしてほしいですね。 世間ではサービス層だなんだと言われていますが、何となくapp/servicesなんてディレクトリを作り満足し、後で負の遺産とか言われるのはとても辛いです1。そもそもRails使ってるのはレールに乗るためなので、なるべく賢い人が作ったレールに乗って生きていくのが正義だと思っています2。 ということで、私たちの会社では Trailblazer というgemを使い始めたので、ここで少し紹介します。 もちろん元気よく本番で動いてくれていますよ。 Trailblazerとは？

設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ

Railsdm 2018 Day4 Nouvelle Vague section B [15:50-16:10 ] Rails アプリケーションの成長に伴い、単一の ActiveRecord モデルにロジックを記述するのに不都合が出てきます。今回、それらの問題を『緩やかに』解消するための Appl…

January 29, 2021 @ 銀座Rails #29

Talk at Rails DM Day3 extreme See also https://railsdm.herokuapp.com/issues/78

クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により

更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive

Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「メルコイン決済マイクロサービスのトランザクション管理を支える技術」の書き起こしです。 @susho：それでは「メルコイン決済マイクロサービスのトランザクション管理を支える技術」というタイトルで、Merpay Payment Platform Teamの@sushoが発表します。よろしくお願いします。 僕の名前は、Shota Suzukiです。社内では、@sushoというアカウントで活動しています。所属は、株式会社メルペイのバックエンドエンジニアです。20

どうも、かとじゅんです。 松岡さん(id:little_hands)が以下の記事を更新されたそうです。松岡さん自身が悩まれた中で検討したオプションであって、唯一の正解ではないと踏まえたうえで、率直な感想を述べたいと思います。結論からいうと、論旨は前回の記事と変わりませんが、コード例で具体的な考え方を示している点を工夫しています。 little-hands.hatenablog.com 前回の考察記事も古くなったので、最新の記事に併せて考察をまとめ直したいと思います。 blog.j5ik2o.me ドメインモデル ドメインモデル図が追加されていますね。以下の３つの集約があるそうです。「一つの集約にまとめればいいよね」という提案はなしという前提で考えます。 ユーザー タスク アクティビティ・レポート 「アクティビティ・レポート」は「タスク」もしくは「ユーザー」に関連を持つようです。 「これらの

久しぶりにブログ記事を書きますか。 ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。 この記事は古くなったので、ぜひ以下も参照してください。 blog.j5ik2o.me little-hands.hatenablog.com 題材も松岡さんのブログ記事と同じもので考えます。 「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。 注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。 class CreateTaskUseCase1( private val taskRepository: TaskRepository, private val taskReportRepository: TaskReportRepository

DDDでは 集約 = トランザクション境界 でなければならないので、 複数の集約をまたがるデータの永続化処理は結果整合性になる。 なぜ集約をまたいでトランザクションをかけてはいけないのかというと、 集約で「データの一貫性の境界」を表現するため。 なので、集約同士はデータの一貫性を保証しない = 結果整合性 ということになる。 集約がトランザクション境界ではない場合はどうなるのかというと、「データの一貫性の境界」がドメインレイヤで表現できなくなる。 あるときは 集約A, 集約B が一緒のトランザクションで登録され、 あるときは 集約A, 集約B, 集約C が一緒のトランザクションで登録される、というケースがあると、 「データの一貫性の境界」はアプリケーションレイヤのトランザクション開始から終了までのコードで表現されてしまうので、 それぞれの集約がどの粒度で一貫性を保たれるのかが分からなくなる

概要 マイクロサービスでは、移行する際にシステム移行に伴うDBの分解が発生した場合に、分散トランザクションは推奨していません。参照: マイクロサービスに移行した際の分散トランザクションの危険性 簡単に説明するなら分散トランザクションは、不具合となる危険性がある為です。 そのため、マイクロサービスで複数のリソースの結果整合性を利用する方法として、Sagaパターンがあります。 Sagaパターンとは Sagaパターンとは、結果整合性を使ったアーキテクチャの1つであり、複数の状態変更を調整できリソースを長時間ロックすることがないよう設計されたアーキテクチャパターンです。「Sagaの元々のアイデアは、Hector Garcia MolinaとKenneth Salemによって発表された論文から生まれました。」 もう少し詳しく説明すると、結果整合性を担保したい範囲を１つのローカルトランザクション(擬似

こんにちは、プラットフォームチーム所属のまこたすです。 昨今、様々な場で「モジュラーモノリスを導入した」という話を目にするようになってきました。弊社でも昨年からモジュラーモノリスの試験導入を進めており、社内でノウハウが徐々に溜まってきたため、今回 技術ブログ で なぜ導入したのかと知見の共有 をさせていただけたらと思います。 想定読者 モノリスなアプリケーションの分割を検討している Railsへのモジュラーモノリスの導入を検討している 話さないこと チーム体制がどうあるべきかという観点の話 以下アーキテクチャについての詳細 モノリスアーキテクチャ モジュラーアーキテクチャ 背景 今回「モジュラーモノリスを導入した」というタイトルですが、最初に検討・導入に至るまでの背景について触れたいと思います。 hacomonoという組織・サービスの成長 hacomonoというサービスはリリースから現在に

私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し

最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで Qiita の初記事にしてみようと思います。 こちらの記事は GUI や CUI のアプリケーションを対象にしています。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/?preview_id=1263&preview_nonce=542ba7b70f&_thumbnail_id=1293&preview=true その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 より実践的なコード（WEBアプリケーション）: https://github.com/nrslib/itddd/tree/master/CleanLike YouTube での解説（WEBアプリケーション）：

こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ

When teams use Code Climate to improve the quality of their Rails applications, they learn to break the habit of allowing models to get fat. “Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle (SRP). “Anything related to what a user does” is not a

I work on several large and mature Rails applications and have recently been feeling a lot of pain as these applications become more and more complex. I started examining where these issues were occurring in our code bases, taking a hard look at how we got there, and doing lots of research of why these things are they way they are. It wasn’t until I came across Piotr Solnica’s dry-validation gem a

はじめに おてつたび の川尻（@tomoki_kawajiri）です。 先日、株式会社ラクスさん主催の エンジニアの勉強法ハックLT- vol.10 に登壇させていただきました。 今回はその中で触れた Trailblazer の概念を取り入れた件についてご紹介します。 登壇資料は以下になります。 内容はフレームワークから学べるメリットやソースコードを見る観点が中心になります。 フレームワークを学習する中で出会った一つが Trailblazer でした。 Trailblazer Trailblazer は Ruby のフレームワークです。 ビジネスロジックを独自のレイヤーでカプセル化することで、責務の分離を果たし、ワークフローをシンプルにできるところが特徴です。 導入の背景 Ruby といえば Ruby on Rails ですが、柔軟性が高いがゆえに長く運用していると MVC のどれかにロジ