graphql-design-tutorial/lang/TUTORIAL_JAPANESE.md at master · Shopify/graphql-design-tutorialYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
アーキテクチャ 【まとめ】 -マイクロサービス、ミニサービス、モジュラーモノリス、モノリシックアーキテクチャを並べて比べてみました- - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。 ラクスでは有り難いことにサービスが順調に成長しています。今後の成長に対応できるようにするために、継続的な検討課題としてより拡大可能なアーキテクチャの検討を行っています。 拡大成長可能なウェブアプリケーション（のバックエンド）アーキテクチャとしてすぐに挙がるのが「マイクロサービスアーキテクチャ」だと思いますが、マイクロサービスアーキテクチャが一般的に議論されるようになったのが2015年頃からだったと思います。それ以来いろいろと考え続け、従来のモノリシックアーキテクチャ群との間にあるアーキテクチャとイメージがつながってきたのでまとめてみたいと思います。 この記事でそれぞれのバックエンドアーキテクチャを俯瞰的に比較する
Microservices分割大全 - kawasima
microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。
AWSマルチアカウントにおけるIAMユーザー設計戦略を考えてみる - How elegant the tech world is...!
はじめに 2020年3月以来の投稿になりますが、「AWS案件に携わる中で、いろいろと貯まった知見を世のエンジニアの皆さんと共有したいな..」という思いに突然駆られ、本稿ではAWSマルチアカウントにおけるIAMユーザ設計の戦略をご紹介します。 ビジネスの要件・制約等により、取り得る設計は様々ですが、一つのベストプラクティス例としてご参考になればと思います。 IAMポリシーに関する基本方針 カスタマー管理ポリシーの利用 AWS利用において、避けては通れないIAM設計。 AWSでは、AWSアカウント（ルートユーザー）の通常利用は推奨しておらず、 AWSアカウント作成後は速やかにIAMユーザーを作成される方も多いのではないでしょうか。 AWS アカウントのルートユーザー 認証情報を使用して AWS にアクセスしないでください。また、認証情報を他のだれにも譲渡しないでください。代わりに、AWS アカ
ドメイン駆動設計本格入門で学び、そして学びほぐされた #devlove - STEAM PLACE
ドメイン駆動設計本格入門に参加してきました。 devlove.doorkeeper.jp 講師は増田亨(@masuda220)さんでした。 概要説明ではなく、開発現場にドメイン駆動設計を導入し、その効果を最大化するための勘所を実コードを使いながら解説します。 とあるように、抽象の話ではなく具体を学ぶことができる講習でした。 以下、講習の中からとくにドメイン駆動設計にフォーカスして内容をまとめていきます。 ドメイン駆動設計本格入門 from 増田 亨 www.slideshare.net ドメイン駆動設計でなぜつくるのか 3つのキーワード ビジネスルール モデル ビジネスルールのモデリング 値オブジェクト 契約による設計 ロジックを持ったenum コレクションのカプセル化 エヴァンス本のススメ パターンについて 責務のレイヤー マイクロサービス アプリケーション層の複雑さ VETRO Sag
https://blog.animereview.jp/zero-trust-architecture/
シンジです。社内インフラを構築するとき、何を指標として設計しているか、何のために作るのか、誰が嬉しいのかを考えずに淡々と予算を投入している企業の多いこと多いこと。これから会社を作るならまだしも、既存企業は長年の蓄積があるわけです。物理機器や、買収合併の弊害、シャドーITに働き方改革推進の圧力。これらに個別的に対処することこそが無駄かつ自己満足なので、自社のインフラはどうなるべきだったのかを考えたい物です。 ITは企業にとってコアである 企業や組織運営において、ITを使うことで便利になったり、効率が良くなったりする程度の時代はとっくに終わっています。企業や組織からIT全てをとっぱらってしまうと、企業や組織が消え去る可能性が非常に高い、というか確実に死ぬであろう状態にまでITに依存しています。つまり現代においてはITはコアなのです。 情報システム部門はその重要性を理解していない 企業においての
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
安定性のパターン大全 (とその実装) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッ
.NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs
If you were looking for MSDN or TechNet blogs, please know that MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. How to use this site Archived blogs are grouped alphabetically by the initial letter of the blog name. Select the initial letter from the TOC to see the full list of the blogs. You can also type the name of the blog or the title of the
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
エラーメッセージは 2W1H がいいんじゃないか
良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 本気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か
FiNC DDD第一回勉強会
Apr 21, 2016Download as PPTX, PDF49 likes12,327 views
SmartNews TechNight Vol5 : SmartNews AdServer 解体新書 / ポストモーテム
広告システムを全く知らなかった私が約2ヶ月弱の開発期間で初期バージョンをローンチ、アーキテクチャも日々変更していき、あれから1年が経過しました。 SmartNews Adsは一般的な広告配信サーバとは異なる特徴をいくつか持っています。今回は運用型広告と純広告型の配信サーバのアーキテクチャを中心に、個人の裁量でどのように設計し、何を採択し、どのように変更していったのかを可能な限り公開し、発生した障害（課題）も晒しながらポストモーテムをします。Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン軽視のメンタルモデル
似非サービスクラスの殺し方 / #ginzarb
設計の「なぜ」を考える | タイム・コンサルタントの日誌から
ログ設計指針
