タグ

関連タグで絞り込む (19)

タグの絞り込みを解除

architectureに関するcpwのブックマーク (11)

  • Why, after 6 years, I’m over GraphQL

    GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h

    cpw
    cpw 2024/06/01
    流行ってるからといって採用するのは良くないよね。ちゃんと評価して本当に効果あるのかどうかを見極めないと。
    リンク

  • レイヤードアーキテクチャを振り返る - Sansan Tech Blog

    こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。

    レイヤードアーキテクチャを振り返る - Sansan Tech Blog

  • 最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita


    TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる﹁イベントストーミング﹂がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で﹁結構日本でやられている取り組みとちがうなー﹂と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守︵あるいは鹿鳴館精神︶ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも﹁ドメインイベント﹂として実装パタ
    最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
    cpw
    cpw 2022/02/26
    イベント駆動はソースコードから呼び出し先が見えないんだよね。ソースコード外に仕様を記述するし、そのせいでIDEの機能は制限されるし、スタックトレースも途切れる。自分が設計するならそうしないかな。
    リンク

  • さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ


    ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で﹁俺ら高凝集低結合だなー﹂と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は﹁導入しましょう﹂﹁既に適用してあるのでキャッチアップしてください﹂などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
    さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
    cpw
    cpw 2020/06/29
     "しかも永遠に正解を議論"これはあるなぁ。で、どっちも正解！みたいなやつでも無駄な議論がすごく発生するイメージ。ドメインはこれがすごく発生するからあまり良くないと思ってる。  

    ●アーキテクチャ
    ●architecture
    ●設計
      
    リンク

  • 分散システム処理モデルに関する動向について（MapReduceからBorgまで）


    詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化︵限定︶されたモデルであったと言えます。 また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。 関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。 純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
    分散システム処理モデルに関する動向について（MapReduceからBorgまで）

  • 続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi


    三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン2‥エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数︵
    続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi

  • The Twelve-Factor App （日本語訳）

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知


    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

  • RIA のアーキテクチャー概要 （リッチクライアント編） | デベロッパーセンター

    コミュニティーリソース Flex cookbook* (コードの共有) CSS Advisor (ブラウザ別バグ修正) Exchanges* (コンポーネントの共有) Adobe Labs* ユーザフォーラム RSS フィード* Flex バグベース* ユーザグループの検索* ユーザグループについて* Adobe Community Experts (ACE)* デベロッパーイベント* ブログ MXNA* (ブログアグリゲータ) Adobe ブログ* この記事では、Flex アプリケーションのアーキテクチャー概要を扱います。以下の内容は、Flex アプリケーション構築の際に一般的に起こる、と思われる問題への対応例を紹介することが目的です。Flex アプリケーションを常に同じ形で構築することを推奨するものではありません。 クライアント側とサーバー側を含めたアプリ全体のアーキテクチャーについて

  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • スケーリング用語の混乱 : やむにやまれず


    2009年05月03日20:19 by 山崎泰宏 スケーリング用語の混乱 カテゴリ Tweet sparklegate Comment(0)Trackback(0) Cloud Application Architecturesを読んだクラウドらしいアプリケーションとは何かという本で、SaaSやPaaSなどにも触れられてはいるが、ほとんどAmazon EC2の話を中心にしています。英文も読みやすいのでオススメ。セキュリティの辺りは結構良いかもしれない。 本書でScalingの用語について整理があり、これはWakameの参考になると思ったのでメモします。 Dynamic ScalingProactive ScalingReactive Scaling著者の分類によれば、Wakameが担うのは、Dynamic Scalingであり、その中でもProactive Scalingに該当するようです
    スケーリング用語の混乱 : やむにやまれず
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.