タグ

architectureとProgrammingに関するiihiroのブックマーク (3)

  • アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD

    注釈: CASH LAYER:キャッシュレイヤ FRONT END:フロントエンド ASSET SERVE:アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER:ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD:クラウド ALL READS! :全ての読み込み WRITES:書く READS:読む MASTER:マスタ INPORTANT POINTY THINGS:重要な鋭い情報 MULTI MASTER DB CLUSTER:複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

    アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
  • ソフトウェアアーキテクトが知るべき97のこと

    ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中!すべてのソフトウェアアーキテクトにおすすめのがウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン

    ソフトウェアアーキテクトが知るべき97のこと
  • アーキテクチャ設計の難しさについて - arclamp

    アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ

    アーキテクチャ設計の難しさについて - arclamp
  • 1