タグ

システムとアーキテクチャに関するten-gallon-Mouseのブックマーク (5)

  • Modular Monolith(モジュラーモノリス)についてまとめる

    モジュラーモノリスについて 目次 モジュラーモノリスとは メリット デメリット・課題 採用例・実装例 必要・向いているケース 不必要・向いていないケース そもそもマイクロサービス メリット デメリット・課題 マイクロサービスを選択する理由 マイクロサービスを採用すべきでない時 とりあえずまとめ そもそもモノリス デメリット・課題 モノリスの種類 参考 モジュラーモノリスとは モノリスからマイクロサービスへでは単一プロセスのモノリスのサブセットと紹介 独立して作業が可能なモジュールで構成され、デプロイ時に結合 モノリスアプリケーション内で、ドメインモデル等を単位としてモジュールに分解し、モノリスのように1つのデプロイパイプラインだけを持ちつつも、マイクロサービスのようにシステムのモジュール化・独立性を両立 マイクロサービスアーキテクチャの場合OrderサービスやPaymentサービス等が独立

    Modular Monolith(モジュラーモノリス)についてまとめる
    ten-gallon-Mouse
    ten-gallon-Mouse 2023/10/12
    “まり、組織はパフォーマンスを犠牲にして、運用上のメリットのためにマイクロサービスを採用しているのです。また、マイクロサービスをサポートするために必要なインフラを維持するためのコストも負担しなければな
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    はじめに 稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、5年も

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    はじめに 稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、5年も

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • Microservices分割大全 - kawasima

    Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ

    Microservices分割大全 - kawasima
  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
  • 1