タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか？ ～関心の分離と疎結合～」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか？」ということを、理解いただくのが本日のゴールとなります。 というわけで本
はじめに コード上での問題を正確に認識しておかなければ、問題を繰り返すのです。Reactを使用したプロジェクトに参画したり、OSSプロジェクトのソースコードを散見すると複雑な仕様に立ち向かったUIに出会うことがあるでしょう。 複雑な仕様に立ち向かったUIは以下の特徴があると考えています。 bundle size が肥大している 保守や維持の管理が高い 他開発者にこのUIは何をやっているのか、質問をしなければならない。 質問の回答を聞いてもそのUIが実行していることが多様で理解しづらい。 再利用性が低い そのUIを利用するために満たさなければならない条件が多く、新しく似ているUIを実装することになる。 複雑なAPI 片手の指の数では溢れる props の数が存在している ユースケースを満たすために、既存の機能を使えば実装ができるのか、判断がしづらい 上記のようなUIを見かけた場合、どのような
SlackとGitHub Deployments APIで疎結合なChatOpsを実現する - Sexually Knowing
下記で紹介している /github deploy というコマンドは2021年4月9日の更新で現行のSlack連携からは削除された。 Removed deploy command and notification support: Today, the functionality provided by deploy command is very limited and doesn't address all the scenarios. We are removing deploy command and notifications support as part of this version. We want to relook at the scenarios and build a more holistic experience that customers need. int
『データモデリングでドメインを駆動する ――分散／疎結合な基幹系システムに向けて』”基幹システム”とは何か、どう作るのか、ということへの道標を示してくれる1冊 - Magnolia Tech
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて 作者:杉本 啓技術評論社Amazon 著者の杉本啓様より献本いただきました。 「基幹システム」……よく考えると最近だんだんと聞く機会の減ってきたキーワードです。たまにメインフレーム上で動くCOBOLで組まれた基幹システムが負債になっている、といった比較的後ろ向きな話題の文脈で出てきて、あまり「攻めた」話題の文脈では出てこないイメージがあります。 本書は、この「そもそも基幹システムとは何か？」、その基幹システムの中心にある「帳簿」とはどんな役割を果たすのか？それらを支える「データモデル」はどのようなもので、どのような設計になるのか？といったことが、長年経営管理システムを作ってきた経験に裏打ちされた知識をもとに分かりやすく解説されます。 この手の、業務システムの設計の考え方、「要件に沿って設計する」以上の解説がなかな
技術用語を比喩から学ぼう ! - 第 1 回「疎結合」 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
builders.flash 読者の皆さん ! こんにちは ! テクニカルトレーナーの吉田慶章です。 builders.flash には様々なカテゴリがありますが、本記事は「How to be a Developer」というカテゴリーに所属しています。エンジニアを目指している方やインフラエンジニアからアプリケーションエンジニアにロールチェンジを目指している方などを読者層とし「どうやってエンジニアになれば良いのだろう ? 」をテーマにしています。 そして、本記事は「初学者が理解しにくい技術用語を現実世界の比喩で紹介する」シリーズです。トレーニングの場でも比喩を使って説明することが重要になり、私自身とても意識しています。
モノリシックなアプリケーションを疎結合にする取り組み - 弁護士ドットコム株式会社 Creators’ blog
こんにちは。弁護士ドットコム クラウドサイン事業本部 Product Engineering 部の須山と申します。CloudSign はサービスを開始してから約 7 年が経過しています。その間数多くの機能追加・拡張を続けている中で技術的な負債を残していくことは、どの企業でもよくある話ではないでしょうか。そんな中 CloudSign では技術的負債を解消することを主な目的としたチームを 2 年程前から結成して、日々改善活動を進めています（それ以外にも、新機能の技術検証や基盤開発も担当しています） 今回はチーム発足時から活動しているモノリシックアプリケーションの分割に関してやってきたことをまとめました。これまでの活動を大きく 3 つの段階に分けて紹介します。 その1. モノリシックなアプリケーションの分割 ローカル環境とそれ以外の環境での差異 アプリケーションを実行環境ごとに分割 アプリケーシ
マイクロサービスをどう切り出すか ～マイクロサービスの凝集性・疎結合性を保つベストプラクティスと最適手法 - アイマガジン｜i Magazine｜IS magazine
マイクロサービス・アーキテクチャで 避けて通れない「切り出し」の話題 マイクロサービス・アーキテクチャに関わる話題は、以下の2つに大別される。 ・「モノリス」と呼ばれる大きなシステムから、どのような指針に基づき、マイクロサービス（注1）を切り出すか。 ・切り出されたマイクロサービスを組み合わせ、どのようにシステムとして機能させるか。 注1：本稿ではマイクロサービスを「十分に絞り込まれた責務が割り当てられた、凝集性・疎結合性に優れるWebサービス」と定義する。 このうち前者は、「なぜ、システムにマイクロサービス・アーキテクチャを適用するのか」という「Why」の話題として捉えられる。 それに対して後者は、「粒度が細かいマイクロサービスを組み合わせてシステムを構成することで生じる課題に、どのように対処すべきか」という「How」の話題と考えられる。 そうした意味では、システムからのマイクロサービス
はじめに やめ太郎さんによる記事 の末尾で紹介されている、「render hook と Promise を組み合わせた方法」について、簡潔に解説し、そのメリットも併せて述べます。 2番煎じですが、そのネタの提供者は僕なので #@!*... (循環参照エラー) Promise を使うことのメリット Promise を使うことによって、確認ダイアログの「確認ボタン」「キャンセルボタン」を押下したときの操作が、ダイアログ側ではなく、ページ側(ダイアログ呼び出し側) に 記述できるようになります。そのおかげで、深くなりがちな関数呼び出しの階層を浅くして、コードを追いやすくなります。 ▼ こんな風に、簡潔でありながら、 階層が浅く、「モーダル操作と種々の処理」の記述が一つの階層にまとめて記述できています。 const { renderDeleteDialog, confirmDelete } = u
ベゾスの掟とAzureと疎結合 - Qiita
餅は餅屋でという親からの厳格な教育の元、本は本屋で買っていたのも、今や昔。Amazonで何でも買う子に育ってしまったし、エンジニアやっているとAWSという言葉を聞いたことがないなんて不届き者はきっといない。 そんな思いの元、どうしてオンライン本屋さんが、AWSなんてクラウドサービスを作れたのか、その元になったベゾスの掟と、その後のプロセスが面白かったという話1。そしてやっぱり核の部分はAzureのサービスのコアに相似してくるのだなと思った。そんな話です2。 結論含め、だいぶ迷子感があるのですが、一旦あげます。（そうしないといつまでも手元に残りそうなので）なので、近日大幅修正発生するかもしれない、そんな記事だと思ってお楽しみください。 ベゾスの掟からAWSへ 2002年ごろにAmazonにいたSteve Yegge氏。彼は、2011年のある日、Amazon, というかそのCEOのジェフ・ベゾ
関わりが深ければ深いほど、 離れるのに痛みを伴う。 体の一部になってしまうから、 密結合とでもいうのかな。 だからって、 色んなものと自分を切り離して、 「自分とは関係ありません」って、 そういう生き方をしていたら、 虚しさばかりを感じてしまう。 痛みを伴うことになっても、 人は何かと繋がらないと生きてはいけないのだ。 それを失いたくないから必死になって、 それを奪われようとするから怒りが生まれて、 「自分らしさ」を守るために人は生きているのかな。 心を動かし続けるのだ。 そうして喜びも悲しみも、 痛みや怒りさえも自分の一部として受け入れる。 「生きる覚悟」って、 きっとそういうもの、 何かがあるたびに振り回されて、 心を揺さぶられて、 痛みを感じて、 そういう経験ばかりしていると、 心を動かすことを恐れて、 心が動かないように努めるようになる。 「生きてきた証」 そういうものって心を動か
アプリケーション開発の現場では長らく「疎結合」がトレンドです。 わたしが疎結合を取り入れた開発プロジェクトに参画したのは2000年です。 オブジェクト指向設計をしたアパレルメーカーの生産管理システムの開発プロジェクトです。 アパレルのサプライチェーンは下記の流れです。アパレルメーカーは製造工程の一部を外部に委託することが多く、生産管理システムは、製造工程の進捗状況を把握する機能が求められました。 アパレルのサプライチェーン 生産管理システムには、委託先への発注や生産指図、進捗状況の登録と、参照機能を組み込みました。専用のWebアプリケーションを通じて、製造のコラボレーションをする仕組みを開発しました。 「疎結合」を意識したのは、ITのトレンドに乗っかる意味合いもありました。 でも、それだけが理由ではありません。 アパレルメーカーを支える基幹システムは、生産以外にも、商品を小売店に配分する仕
【AWS グラレコ解説】アプリケーション同士の疎結合を実現。「Amazon SQS」をグラレコで解説 - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
※ 本連載では、様々な AWS サービスをグラフィックレコーディングで紹介する awsgeek.com を、日本語に翻訳し、図の解説をしていきます。awsgeek.com は Amazon Web Services, Inc. プリンシパル・テクニカル・エバンジェリスト、ジェリー・ハーグローブが運営しているサイトです。 これまでのグラレコ解説はこちら » 近年、「モノリス」と呼ばれる単一の大きなアプリケーションから、複数のモジュールで構成される「マイクロサービス」あるいは「サーバーレス」と呼ばれるアーキテクチャへ移行するケースが増えてきています。 今回ご紹介する Amazon Simple Queue Service (Amazon SQS) は、マイクロサービス や サーバーレスアーキテクチャ において、アプリケーション間をつなぐ、コーディネーターのような役割を担うサービスです。具体的に
2023/06/14開催の「〜プロダクトを愛するアーリースタートアップが語る〜 エンジニアLT・交流会」（ https://ascend.connpass.com/event/284072/ ）にて登壇した10分LT資料。
この記事は「連載：技術基盤強化プロジェクト「RFS」の現在と未来」として書かれたものです。 メルカリCS Tool チームでTech Leadをしている @hukurou です。前回はトランザクションチームの取り組みを紹介しました。今回はCS Toolチームが取り組んでいる、メルカリのカスタマーサービスツール（以下、CSツール）のDBへの依存の削減や、その依存箇所を検出するための静的解析ツールの開発について紹介します。他の取り組みについても、この連載内で他のメンバーが紹介する予定です。 「RFS」におけるCSツールの目標 RFSとは「Robust Foundation for Speed」の略で、メルカリが将来に渡って力強く、素早く成長し続けるために、今あるビジネス共通基盤の複雑な技術的問題を解決していく取り組みです。以下の記事では、より詳細にプロジェクトの目的や取り組みについて説明してい
はじめに Compositional LayoutsがWWDC2019で発表され、ここ数ヶ月でようやくiOS13以上をターゲットにしたプロジェクトが増えてきたのではないでしょうか？ SwiftUIを取り入れている技術の記事も目立ってきましたが、iOS14にならないと不自由も多く、最初から機能が豊富なCompositional Layoutsを選択するのも１つの判断かと思います。本記事では実際にプロジェクトに導入してみたので、どのような構成で導入してみたのかをまとめています。 追記：iOSDC2021 のスポンサーセッションでも発表しました。資料はこちら。 Compositional Layouts の優位性 そもそも、Compositional Layoutsで組むことは、何がメリットなのかというお話をざっくりしておきます。 1. UICollectionViewDelegateFlowL
![[Swift] Compositional Layoutsで実現する疎結合な実装 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/12bfddadd2915e0fc4130d2681809d635f97be2e/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCU3dpZnQlNUQlMjBDb21wb3NpdGlvbmFsJTIwTGF5b3V0cyVFMyU4MSVBNyVFNSVBRSU5RiVFNyU4RiVCRSVFMyU4MSU5OSVFMyU4MiU4QiVFNyU5NiU4RSVFNyVCNSU5MCVFNSU5MCU4OCVFMyU4MSVBQSVFNSVBRSU5RiVFOCVBMyU4NSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ODAwYjczMzdjYzdiMDk4ODA3MWYwMGNkZDZiYzlmMGU%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBoY3JhbmUmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTNiNjJlMGJiOGJhZGYwZWRlMzFiNmE5YjAxMGY1YWVi%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qW95aSp44Kw44Or44O844OX5qCq5byP5Lya56S-IOODqeOCr-ODnumWi-eZuuODgeODvOODoA%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3De52e507d27bfd2271404b6879338f0e1)
『なぜ依存を注入するのか DIの原理・原則とパターン 』を読んで、”疎結合なアプリケーション”とは何かを考える - Magnolia Tech
なぜ依存を注入するのか DIの原理・原則とパターン (Compass Booksシリーズ) 作者:Steven van Deursen,Mark Seemannマイナビ出版Amazon なんとDI(Dependency Injection)だけを扱う本の厚さが637ページ! たぶん、もう日本で今後商業出版されることは無いであろう、DI(Dependency Injection)の解説書『なぜ依存を注入するのか DIの原理・原則とパターン 』を読みました。 はじめてDIに触れたのはGoogle Guiceだったのですが、いつの間にかオブジェクトがフィールドに生えてくる黒魔術的なテクニック、という印象でした。 ”動的に実装を切り替える”、という意味ではPerlで実行時に設定に応じて実装を切り替えるモジュールをたくさん見てきたし、自分でも書いたことが有ったので、Javaなどの言語で実行時の実装選
Dockerで Nginx + uWSGI + Flask の疎結合なWebアプリケーションサーバーを構築する - Qiita
docker composeやソケットファイル無しでソケット通信を使用した nginxコンテナ ⇔ uWSGIコンテナ（Flaskアプリ）環境を構築する方法です。 ※本稿の設定例そのままの値だとIP直指定しており、疎結合とは到底言えない状態のため、最終的にはサービス毎にAPIエンドポイントを作成するなど設定値を置き換えて利用ください。 それぞれのサービスを疎結合にして、マイクロサービスなアーキテクチャ設計をするために、サービス毎にコンテナを細かく分割するケースは多いと思います。 ただ、ロードバランサーやプロキシ、APIエンドポイントなどを用いず、コンテナを独立させながら直接疎通させるのは手間で疎結合にも出来ないので、特別な事情が無ければ止めた方が良さそうです。（あまり例も見かけないですし） 例えば、自動起動設定のコンテナを起動しているホストマシンが再起動された場合、コンテナのIPが変わって
Google Cloudで理解する疎結合アーキテクチャとメッセージングサービス - G-gen Tech Blog
G-gen の杉村です。Google Cloud (旧称 GCP) で Pub/Sub を中心とした疎結合アーキテクチャについて解説します。 はじめに 疎結合アーキテクチャとは 非同期処理 同期と非同期 同期処理 非同期処理 疎結合アーキテクチャと非同期処理 メリット メッセージングサービスが必要な理由 拡張性の向上 保守性の向上 可用性の向上 なぜクラウドらしいのか 用語 コンポーネントの用語 挙動の用語 pull と push FIFO (message ordering) At-least-once (最低1回の配信) アーキテクチャの用語 広義の Pub/Sub Fan-out (ファンアウト) Google Cloud での疎結合アーキテクチャ キーとなるサービス「Pub/Sub」 AWS との比較 Cloud Pub/Sub vs Cloud Tasks サンプルアーキテクチャ
疎結合というトレンド - 叡智の三猿
前回は「2025の崖」の問題と、SAP ERPを保持し続けるリスクについて書きました。 www.three-wise-monkeys.com まとめると、2000年代に一世を風靡したERPは、密結合という特徴があります。密結合のシステムは拡張性に難点があり、変化の多い市場環境に迅速に対応するのが苦手です。Webアプリケーションがシステムの主役になって以降、密結合よりも疎結合のシステムの方が優れているとみなされています。 疎結合とは、2つのシステムが緩やかに結びついた状態をさします。疎結合なシステム間の連携を果たすのがAPI（Application Programming Interface）です。 たとえば、B2B向けとB2C向けに商材を販売している会社があり、B2B向けにはSalesforceを使って商談管理を行い、B2C向けにはAWS上にECサイトを構築しています。Salesforce
OpenAPI(Swagger)を用いたフロントエンドとバックエンドを疎結合にする開発 - M&Aクラウド開発者ブログ
こんにちは。エンジニアの鈴木（@yamotuki）です。 今日はAPIドキュメントを書くことでフロントエンドとバックエンドの開発を疎結合にして平行して開発を進めている話を書こうと思います。 疎結合とは？ 通常の開発フローだとバックエンドAPIを先に実装して、そのあとでフロントエンドの開発を進める必要があります。これはAPIからどのようなレスポンスが帰ってくるかわからないので、フロントエンドは先に実装することはできないと言う事情があります。では、APIを完全に実装しきってからではないとフロントエンドの開発がすすめられないのか、というとそうではないと考えています。 依存関係逆転の原則（DIP）の考え方を導入すると、フロントエンドが依存する対象を変えることができます。DIPを一言で言うと "詳細に依存するな、インターフェースに依存しろ" だと私は考えています。 依存性逆転の原則 - Wikipe
© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. connect DevAx 「疎結合」を実現する メッセージングサービスの選択と利用 sugishin@amazon.co.jp Shingo Sugimoto Solutions Architect, Industry Solutions Amazon Web Services Japan K.K. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. 自己紹介 杉本 晋吾 Shingo Sugimoto 技術統括本部 インダストリーソリューション部 ソリューションアーキテクト (SA) 略歴 現在 ← 海外開発製品の技術営業 ← ITコンサル会社の
ブロックチェーンの優位性 ブロックチェーンの議論が盛り上がってきましたが、まだまだ理解されてないと思うのでNoteにしました。 ここで言うブロックチェーンとはプライベート・ブロックチェーンを想定していますが、疎結合に関してはパブリックでも同じことかと。いきなり疎結合から話すと、BCの優位性はそれだけかと反論が予想できますが、ビザンチン耐性やImmutabilityはあとで説明するのでお待ちください。 プライベート・ブロックチェーン miyabi 疎結合とは？疎結合とは、細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことである。疎結合では、個々のコンポーネント同士は相互に連携しているが、相互に依存している余地が少ない。そのためコンポーネント間の連携をあまり顧慮せず、それぞれのコンポーネントを交換したり改良したりするような柔軟な対処を行うことができる。疎結合
アプリケーションの迅速な改善を可能にする「マイクロサービスアーキテクチャー」。国内でも金融機関や伝統企業が導入するなど、本格的な普及期に入りつつある。ただし既存システムへの適用では、アプリケーションを独立性の高いサービスに切り分けるといった難題が立ちはだかる。どうすればうまくいくのか。最新の事例から成功の秘訣を探る。 「マイクロサービスアーキテクチャーとして設計したわけではない。ただし開発スピードや保守性を向上させるために、疎結合の考え方を取り入れた」。SOMPOシステムイノベーションズの木下義猛プログラム推進本部長は、損保ジャパンの新基幹システム「SOMPO-MIRAI」の開発コンセプトについてこう言及する。 新システムに取り入れた疎結合の考え方の1つが、システムの独立性の担保である。JavaベースのWebアプリケーションやコンポーネントは圧縮形式でWARファイルにまとめてデプロイする。
2024年2月24日紙版発売 2024年2月24日電子版発売 杉本啓 著 A5判／400ページ 定価3,740円（本体3,400円＋税10%） ISBN 978-4-297-14010-6 Gihyo Direct Amazon 楽天ブックス 丸善ジュンク堂書店 ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 本書のテーマは「データモデリング」と「基幹系システム」です。 Web上で台頭しつつある新たなビジネスは，新たな基幹系システムを必要としています。一方，既成ビジネスでは，モノリシックで硬直的な基幹系システムをしなやかな姿に変えていく必要があります。 基幹系システムの中核には「構造化されたビジネス記録」＝「帳簿」があ
Vue3で保守性の高いテストコード作成方法を解説！Vue3エンジニアが実装とテストの疎結合実装方法を解説！ | Ragate ブログ
Vue3で保守性の高いテストコード作成方法を解説！Vue3エンジニアが実装とテストの疎結合実装方法を解説！ こんにちは！ 今回は Vue3 でのコンポーネントのテストコードの作成方法を紹介します！ テストコードを書くことでチーム開発はもちろん、個人開発においてもコードをリファクタリングしたり、バグを発見したりする際に重要な役割を果たします。 Vue3 から新たに登場した Compostion API を利用することで、より保守性の高いコンポーネントを定義することができます。 コンポーネントをテストする場合、一般的にはテストコードを実装からできる限り切り離すように作成します。 理想的なのはコンポーネント内のロジックなどを考慮せずに実施するブラックボックス的なテストを書くことです。 はじめに 本記事では Vue3 でのテストコードの作成方法について解説しております。 Vue2 では Vue.e
「出張！ #DevelopersIO IT技術ブログの中の人が語る勉強会」でLambdaとEventBridge Pipesを例にSQSコンシューマーの疎結合進化について語りました | DevelopersIO
弊社技術ブログ「DevelopersIO」の書いた本人が過去記事を深掘って話すという勉強会の第3回が2024/04/18に開催されました。 今回は、2006から本稼働しているメッセージキューサービスのAmazon SQSのコンシューマー処理が2014年のAWS Lambda、2022年のAmazon EventBridge Pipesの登場とともに、疎結合に進化していったことについて、re:Invent 2022の EventBridge Pipes発表直後に書いた次のブログをベースに深堀りました。 EventBridge Pipesは非同期のメッセージ通信で幅広く使えるのに、今ひとつ認知・採用されていないなぁという思いと、相性が良いSQS-Lambda連携について、現在はEventBridge Pipesを挟む選択肢もあることを知ってもらいたくて、このテーマを取り上げました。 勉強会で使
SQSとSNSによる疎結合
コーポレートサイトの可用性、拡張性をさらに高める方法の一つとして、「疎結合」が挙げられます。ここでいう疎結合とは、複雑なシステムを互いに過度に依存し合わないシンプルなコンポーネントに分割することです。疎結合にすることで、各コンポーネントが拡張しやすくなったり、耐障害性を高めたりすることができます。 実はこれまでに強化してきたコーポレートサイトでも、ELB（Elastic Load Balancing）によってWeb・APサーバーを疎結合化しています。Web・APサーバーの1台に障害が発生したとき、ELBが検知してそのサーバーにトラフィックを流さないようにして、システム全体として処理を継続します。 スケーリングでは、Web・APサーバーの仮想マシンを新規作成してELBに登録するだけです。その際、DNS（Domain Name System）のレコードはELBを参照するようにしておくことで、設
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜDependency Injectionなのか？ ～関心の分離と疎結合～
Reactにおける再利用とテストを容易にする疎結合なUIを目指す3つのTips
![なぜRyzenノートを選んだほうがいいのか？CPUだけでなくトータルで強いRyzen AI 300について知っておくべきこと ～旧世代製品との比較検証も実施[Sponsored]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d924029f32667be69a463e3d55e138b1ecbd0088/height=288;version=1;width=512/https%3A%2F%2Fpc.watch.impress.co.jp%2Fimg%2Fpcw%2Flist%2F1623%2F965%2Fimage01.jpg)
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon
render hook と Promise を使ってダイアログを含むフローの記述を疎結合に実現する
疎結合と密結合 - 「童貞のまま結婚した男」の記録
家族にたとえる疎結合と密結合 - 叡智の三猿
コンパウンドスタートアップの“疎結合すぎない”チーム設計
メルカリCSツールにおけるDBの疎結合化への取り組み | メルカリエンジニアリング
[Swift] Compositional Layoutsで実現する疎結合な実装 - Qiita
「疎結合」を実現するメッセージングサービスの選択と利用-AWS-DevAx::Connect.pdf
ブロックチェーンの優位性①疎結合｜加納裕三/Yuzo Kano
損保ジャパンの新基幹システム、開発スピード向上のため何を「疎結合」にしたか
データモデリングでドメインを駆動する ――分散／疎結合な基幹系システムに向けて
yaanavi.com
www.fashionsnap.com
www.sevendesign.biz
www.timeout.jp
www.cmoa.jp
www.chunichi.co.jp