タグ

設計に関するebcmのブックマーク (5)

  • MySQL を使ったお手軽メッセージキュー実装 - ドワンゴ 研究開発ブログ

    はじめに この記事では、MySQL を使って簡単なメッセージキューを手軽に実装する方法を解説します。 メッセージキューとは、メッセージを一時的に溜めておき、順次処理するための仕組みです。迅速なレスポンスが必要な Web アプリケーションにおいて、時間のかかる処理を非同期に行うために、バックグラウンドで順次処理していくような場合に利用できます。 簡単なメッセージキューと言っても、大規模な運用にも耐えられる程度の速度と堅牢性を持ちます。 また、ここで解説している方法で作られたメッセージキューは、弊社ウェブサービスであるニコニコ動画に最近追加されたtwitter連携機能でも利用しています。 メッセージキューを作るにあたって 今回実装するメッセージキューは メッセージの追加(push)を高速に行う事ができる メッセージの取得(pop)はある程度高速に行う事ができる 多くのクライアントから同時に p

  • 仕様(インターフェイス)と実装の詳細 (1) - 都元ダイスケ IT-PRESS

    APIの公開/非公開が意識できるようになると共に、「仕様(インターフェイス)」と「実装の詳細」を意識できるようになるとよい。 このクラスの公開APIはどれか、非公開APIはどれか このクラスの仕様(インターフェイス)はどれか、実装の詳細はどれか という2つの角度でクラスをとらえる。前者については昨日のエントリでも示した通り、可視性がpublic,protectedなものが公開APIであり、その他は非公開APIである。機械的に判断できますね。では後者についてはどう判断すればいいか? 注:下の例で「このクラスのインターフェイスは?」と聞かれると単純に「Baz」と答えるかもしれない。がここで言いたいのは「Bazを介したFooのインターフェイス」ではなく「Foo自身が純粋に外部に公開する仕様としてのインターフェイス」のこと。インターフェイスとは何か?についてはinterfaceについて気出して考

    仕様(インターフェイス)と実装の詳細 (1) - 都元ダイスケ IT-PRESS
  • 可視性と公開APIと非公開(内部)APIと - 都元ダイスケ IT-PRESS

    Javaではpublic, protected, default, privateという4種類の可視性がある。 Javaを始めてしばらくの間、この4つの使い分けがよくできていなかった。 「外から呼ぶならpublic、呼ばないならprivate」時代 当時から、なるべく可視性は下げた方が良い(オブジェクト指向は「隠す技術」である → 継承とコンポジット - 都元ダイスケ IT-PRESS参照)ということは理解していたので、「外から呼ぶならpublic、呼ばないならprivate」という指針からスタートした。 上記に加えて「継承先からしか呼ばないならprotected」時代 Template Methodパターンを覚えた頃の話。この時代が一番長かった。 そして残ったひとつ、default(package-private)の使い方が全く分からなかった時代でもある。色々使おうと頑張ってみたが、pa

    可視性と公開APIと非公開(内部)APIと - 都元ダイスケ IT-PRESS
  • 「RESTful MVC」なアーキテクチャの話

    最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)

    「RESTful MVC」なアーキテクチャの話
  • Web アプリの MVC 設計まとめ - もやし日記

    MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく? まとめ 前提対象は Web アプリケーションで、画面数(ビューの数)は数個〜100個程度の規模です。WordPressTwitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います(そもそも MVC を使わない、など)。 肥大化するコントローラを避ける例えば、八百屋さんで「60円で仕入れたリンゴ1つを100円で売った」こと(Sales Transaction)を記録する場合を

  • 1