BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Patterns に関するすべてのコンテンツ

  • マイクロサービスのアンチパターン

    一枚岩のアプリケーションの主な問題はスケールし難いということだ。しかし、これはアプリケーションの観点だけではなく、チームがスケールし難くなることが重要だ。QCon LondonカンファレンスでTammer Saleh氏は、マイクロサービスの一般的なアンチパターンについて語り、マイクロサービスへ移行する主な理由はチームにある、と話した。

  • Goのプログラミングパターン

    QCon London 2016において、Peter Bourgon氏は「Successful Go Program Design, 6 Years On」というプレゼンを行い、Goでプログラミングするときに使うべきパターンと避けるべきパターンについて説明した。

  • フロントエンドに対するAPIバックエンドの提供パターン

    モバイルデバイスを使ったWebエクスペリエンスは,その小さな画面や限られたデータプラン,要求数を少なくする必要など,多くの点がデスクトップのものとは違う。内容の異なるデータが必要な場合や,バーコードリーダ経由など独特のインタラクションが提供される場合もある。クライアント形式毎にひとつのバックエンドを用意するBFF(Backend For Frontend)はそのソリューションのひとつだ,とSam Newman氏は自身のブログ記事で述べている。

  • Redux - Fluxに影響を受けたアーキテクチャスタイル

    ReduxはFluxと同じように単一方向のデータフローを使用しているが,唯一のストアをクローンすることによって,元のストアに副次的な影響を与えずに機能を提供することができる。ディスパッチャは存在しない。

  • Microsoft Azure Event Hubs、月1兆トランザクションを超える

    Microsoft Azure Service Busプロダクトチームによると、Microsoft Azure Event Hubsメッセージングサービスは2015年6月に、1日当たり約150ペタバイト、300億メッセージ、1秒当たり375,000メッセージを処理したという。

  • Ilan Goldstein氏のScrum Myth Busterシリーズ

    この記事では,認定スクラムマスタであるIlan Goldstein氏による,スクラムの俗説(Myth)に関する説明を取り上げる。

  • CQRSに対する批判的見解

    Command Query Responsibility Segregation(CQRS, コマンドクエリ責務分離)をもっと大きく,アーキテクチャ的コンテキストで眺めてみると,他にも利用可能なアーキテクチャスタイルが存在することに気付く。データベース技術でも,同じ問題を簡単な方法で解決することが可能だ – Udi Dahan氏は,CQRSへのアプローチに関して,このような意見を述べている。CQRSが本当に必要であったとしても,はるかに少ない可動部品で目標の大部分を達成可能な方法も存在する。

  • DDD、マイクロサービス、境界についてEric Evans氏が語る

    マイクロサービスには大きな価値があり、ドメイン駆動設計を実践するための最高の環境を与えてくれると考えている、とEric Evans氏は、ロンドンで開催された、DDD Exchangeカンファレンスのキーノートで講演をした。氏にとっては、イテレーションは良い設計のためにもっとも重要だ。そして、マイクロサービスは良い設計をするためSOA以来の2度目の挑戦だ。

  • CQRSとイベントソーシングのデモアプリケーションを作る

    Command Query Responsibility Segregation (CQRS)に関するアーキテクチャやパターンについて理解を深めるため、Sacha Barber氏はCQRSのデモアプリケーションを開発した。このアプリは、イベントソーシングも活用しており、記事で解説がされている。

  • IODAアーキテクチャについて

    Ralf Westphal氏によると、レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャ、クリーンアーキテクチャといったアーキテクチャパターンはよく似ていて、アプリケーションの構造について非常に大雑把なイメージを与えてくれるという。Westphal氏はアーキテクチャを記述する別の方法を求めて、IODAアーキテクチャというスタイルを定義した。これはオペレーション、データ、インテグレーションという3つのフォーマルな責務で構築される。

  • 集約、エンティティ、バリューオブジェクト

    集約をモデリングして、その集約の中のエンティティから可能な限り多くの振る舞いをバリューオブジェクトに移行しようとするとき、より多くの振る舞いが必要になるにつれ、新しいバリューオブジェクトが必要になる。これは、Paul Rayner氏が集約やエンティティ、バリューオブジェクトなどドメイン駆動設計(DDD)の世界の概念を取り上げた一連のブログ記事の中で推奨していることだ。

  • Fearless Journeyゲームで遊ぶ

    The Fearless JourneyゲームはDeborah Hartmann Preuss氏が設計し、Mary Lynn Manns氏とLinda Rising氏の著書Fearless Changeで取り上げたパターンに基づいて構築されている。このゲームはチームで行い、何の権威もない状態で障害に立ち向かう方法を学ぶことができる。Martin Heider氏とHolger Koschek氏はワークショップを開催し、このゲームを実施した。

  • "Worse is Better"コンセプトとアジャイル/リーン

    25年前にRichard P. Gabriel氏の提唱した“Worse is Better(悪い方がよい)”のコンセプトに従うならば,機能が少ない方がよい製品を生み出せる,ということになる。我々は“Worse is Better”のコンセプトから,アジャイル/リーンによる開発とアーキテクチャを学ぶことができる,とKevlin Henney,Frank Buschmann両氏は言う。

  • アーキテクチャ、技術、そしてアンチパターン「溶岩流」

    アーキテクチャと技術を連続して変えながらアプリケーションを走らせると、脆弱で断片的なコードベースが生まれ、理解やメンテナンスが難しくなる。Mike Hadlow氏は溶岩流または溶岩層とこのアンチパターンを命名し、このアンチパターンが時折表れる理由について自身の経験を書いている。

  • GoogleによるAndroidのパフォーマンスについて

    Google Developers YouTubeチャンネルに、Androidの性能パターンに関する16の動画がポストされている。これらの動画は、開発者がAndroidアプリを開発するときに直面する多くの性能問題について概括しており、アドバイスもしている。この記事ではそのアドバイスを簡単に紹介したいと思う。

BT