失敗知識から学ぶ！クラウドアプリ設計で避けるべき事例とその対策2023/6/22 AWS Dev Day 2023 Tokyo 登壇資料
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
アベイラビリティーゾーンを使用した静的安定性
Amazon で構築するサービスにおいては、非常に高い目標で可用性を達成する必要があります。これはつまり、システムが取る依存関係について、慎重に検討する必要があることを意味します。これらの依存関係が損なわれた場合でも復元力を維持するようにシステムを設計します。この記事では、このレベルの復元力を実現するために静的安定性と呼ばれるパターンを定義します。この概念を、AWS の重要なインフラストラクチャビルディングブロックであるアベイラビリティーゾーンに適用する方法を示します。したがって、すべてのサービスが構築される基盤になります。 静的に安定した設計では、依存関係が損なわれてもシステム全体が動作し続けます。おそらく、システムは、依存関係が提供するはずだった更新された情報（新しいもの、削除されたもの、変更されたものなど）を確認しません。しかし、依存関係が損なわれる前に行われていたすべての処理は、依
Railsにおけるサービス層の導入と感触 - Qiita
http://qiita.com/kbaba1001/items/e265ad1e40f238931468 で Rails のアーキテクチャを改善する話を書きましたが、理屈っぽい話になっていたので、今回は具体例として実際に私が仕事で実践していることについて書きます。 半年ほどサービス層を作りまくっていますが、最高としか言いようがありません。 Modelとロジックが切り離されているので、本番運用をはじめた後もかなり柔軟に開発を続けられています。 (さすがにERに影響がある変更には手を焼きますが...) サービス層を作って Fat Model 対策をすることは Rails 開発において有効な設計だと感じています。 Rails にサービス層を導入する最も簡単でパワフルな手段は Trailblazer を使うことです。 しかし、本記事では Reform を使ってサービス層を自作する方法について書き
Rails：Service層を運用して良かったところ、悪かったところ - Qiita
1年前くらいにRailsの設計にDDD(ドメイン駆動設計)のService層を導入し、Modelの肥大化対策をしました。 この記事では、まずどのようなルールでService層が組み込まれているかと、1年間運用してみて良かったところ、悪かったところの感想を書きます。 [2018/05追記] 最近ではサービス層の導入は賛否両論あるようなので、導入する際は自分のプロジェクトに合っているかどうかを十分にご検討ください！ Service層を導入するきっかけになった問題点 Modelの肥大化 Model間の複雑な依存関係 多数のミドルウェアの導入による複雑さの倍増 これらにより.. メンテナンスやテストがしにくい コードが整理されていないのでとにかく読みづらい Model複雑化の例 <ユーザがECサイトの商品をお気に入り(like)にするメソッドを書く場合> 処理に関連するテーブル my_itemsテ
大規模Rails開発を蝕む5つのアンチパターン | mah365
Railsでアプリを作っていると、最初の立ち上がりは速いものの、コードが多くなってくると結構散らかってきますよね。そんな中、5 ARCHIRECTURE ANTI-PATTERNS AND SOLUTIONS FOR LARGE RAILS APPSという記事を見つけたので、ご紹介します。 1. 複数の責務を持つサービスクラスがある 業務別の処理をサービスクラスという形で分割したときの話ですね。ActiveRecordのクラスに直接仕事をさせるのではなく、プレーンなクラスに業務処理をまとめて、そこからだけActiveRecordのクラスのオブジェクトにアクセスするという考え方です。 で、業務別の処理をサービスクラスにまとめたのは良いんだけど、「これもこの業務だよね」という感じで、どんどんサービスクラスに処理を追加していくと、単一責任の原則に違反してしまうし、混沌とするので、良くないよねと。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
