DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
Access to paperclip temp file when using s3 storage option on heroku
I am using the Paperclip gem to resize upload photos and store them on amazon S3. I need access to the resized photo to also pass along to another web service, during the lifecycle of the upload request. I suspect there is a temp file created somewhere the imagemagik uses before the photo is uploaded to s3. How can I get access to it.
iOSアプリのプロビジョニング周りを図にしてみる - Qiita
きっかけ iOSアプリ公開の壁となっているプロビジョニング周りですが、ハマりまくったので覚えている内に図にしました。 難しくしてる理由 難しくしているのは、この辺が理由ではないかと思います。 iOS Developerサイトでの画面・操作手順がしょっちゅう変わる Xcodeも、バージョンによって画面・操作手順が変わる ということで、書籍やWebでのノウハウがすぐに古くなってしまいます。ググるといろんな情報が出てきてしまい、かえって混乱します。 また、開発時のiOSデバイスはXcode側である程度自動的にやってくれるのですが、それがかえって分からなくしているような気がします。 概念図 ということで、結局、概念を理解してしまうのがいいのではないかと思い、図にしてみました。 （より厳密に実行端末が判断されるAd Hoc配布をベースに記述） ざっくり手順（※個別の操作は省略） 鍵ペア（秘密鍵／公開
mod_mrubyとDockerを使ってプレビュー環境を作成するプロキシサーバを作った - Qiita
この記事は mod_mruby ngx_mruby Advent Calendar 2014 8日目の記事です。 mod_mrubyを使って、プレビュー環境をDockerコンテナで作成するプロキシサーバ「pool」を作りました。 mookjp/pool 主に私と、mod_mruby ngx_mruby Advent Calendar 2014の12日目にエントリーもしているainoyaと2人で開発しています。 poolについて 概要 http://<ブランチ名 or GitのコミットID>.pool.dev/のようなURLへアクセスすることにより、このコミットIDの状態のアプリケーションをプレビューすることができます。 URLへのアクセスがトリガーとなるので、プレビュー用の環境作成を開発者以外が実行することも可能です。 デザイナーやディレクターでも、見たい状態のコミットIDを含むURLをを
モバイルアプリ開発で面倒なサーバAPIバックエンドの切り替えを動的に行う - Qiita
これはリクルートテクノロジーズアドベントカレンダー18日目の記事です． 14日目に出た図にそっくりですね APIエンドポイントを固定したままバックエンドを切り替える モバイルアプリの開発時，サーバ側APIの開発も同時並行で実施している場合，皆さんは開発中のアプリと開発中のサーバの対応をどのようにとっているでしょうか？ 開発のたびにアプリ内のサーバAPIのエンドポイント設定値を変更してアプリをビルドし直す 開発版のアプリはconfig配布サーバから設定を取得し，設定値に記載されたエンドポイントと通信する など，上記のような方法が考えられますが，クライアントアプリ側に開発デバッグ用の機能を作りこんでいくのは面倒で，なるべく少なくしたいのではないかと思います．そこで今回は，モバイルアプリで設定するエンドポイントURLは固定にしたまま，サーバ側でモバイルアプリからのリクエストに応じてバックエンドを
Programmableなproxyで試すOrchestration Layer - Qiita
リクルートテクノロジーズアドカレ14日目です！先日mod_mruby/ngx_mrubyのアドカレで記事を書かせていただきましたが，その勢いでngx_mrubyを使って実験的な試みをしてみました． ProxyでバックエンドAPIを結合する 今年の前半ぐらいに盛り上がった話題で周回遅れ感があり若干の気恥ずかしさがあるのですが，サーバサイドでAPI実装が既に完了してしまっている/改修不能な状態で，クライアントアプリが要求するAPIの仕様がドラスティックに変わるというずれがあるケースで，クライアントサイドのエンジニアがサーバサイド側でAPIをある程度整形できる緩衝地帯的な仕組みがあるは面白いなと，kawasimaさんのdarzanaやnetflixの記事や同僚の話を聞いて考えておりました.SOA,SOAPやWDSLのことが思い浮かばれますが,最近覚えたproxyのリクエスト制御の仕組みを使って同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
