システムの学習曲線とAngularアプリケーションの設計A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
Clean ArchitectureとBuilding Evolutionary Architecturesを読んだ
Clean Architectureという本とBuilding Evolutionary Architecturesという本を最近読んだのでざっくりとしたメモ。（両方共2-3時間ぐらいでざっくりとしか読んでないので、解釈間違いは普通にありそうです） 両方共アーキテクチャに対するメタ的な視点な部分があるので、合わせて読むと面白いかも。 Clean Architecture(Clean Codeの人のシリーズ)という本を読んだ。 Clean Architecture: A Craftsman’s Guide to Software Structure and Design | InformIT PDFとかEpubとかMobiが買える Robert C. MartinのClean *シリーズでいわゆるクリーンアーキテクチャそのものだけを扱ったという内容ではない。 でもクリーンアーキテクチャについ
Service Locator パターンについて - Qiita
会社にて「Service Locator パターン」という単語を聞いて「？」となったので、戒めも含めて調べてみたメモ。 いきなり結論 結論から言うと、Service Locator パターンも Dependency Injection (いわゆる DI )と同じようにクラス間の密結合度を緩和するためのものと考えてよさそう。 というか、こちらに超参考になる記述があるので、これを備忘録として残しておく。 概要 DDDとかの Repository パターンで DI を使用することがあるが、それと同じような目的で使用できる。 なんちゃってサンプルコード ここでは、ドメイン層がインフラ層に依存しないように Repository パターンを使用する場合の、 DI 版と Service Locator 版をそれぞれ考えてみる。 DI 使用したときの Repository パターン // アプリケーション
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
ユースケースによるアスペクト指向(Laravel編) - Qiita
この記事は株式会社アイスタイルアドベントカレンダーの18日目の記事です。 弊社ではPHPをメインで利用しています。 一部のプロジェクトでは表題のアスペクト指向を用いて開発しています。 アスペクトのおさらい 横断的関心の分離をする技術で、アスペクト(AOP)はオブジェクト指向プログラミング (OOP)を補完する技術の一つです。 AOPはポイントカットとアドバイスを利用して定義を行います（AspectJ）。 ポイントカット 後述するアドバイスがどのような条件で実行するかを定義するものです。 例えば、 Hogeクラスのfugaメソッドが実行される時 Hogeクラスの全てのメソッドが実行される時 Hogeクラスのメソッドのうち、setというプレフィックスが付いてるものが実行される時 などがあります（ジョイントポイント）。 言語やライブラリによって定義されているものなどがありますので、 それぞれのラ
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Atomic Architecture
現場で役立つシステム設計の原則で個人的に面白かったところメモ - Qiita