モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層

仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化… システムの健全な成長を妨げる要因に対する基本戦略 アーキテクチャ刷新の現場：未知の技術を採用するために #1/2 アーキテクチャ刷新の現場における取り組みと成果を発表 成瀬允宣氏：みなさん、こんにちは。GMOインターネットグループでデベロッパーエキスパートとして活動しています、成瀬允宣と申します。本日はよろしくお願いします。 私、所属はGMOインターネットグループ株式会社で、システム統括本部に所属している一般のプログラマーではありますが、私からお送りするお話は、「アーキテクチャ刷新の現場」で、ここ数年……2年ほどですかね、アーキテクチャを刷新する現場で一番前を走っていたので、その現場のお話をしようかなと思っています。 非常に苦労して、やっと花開いてきたところなので、今日は、何を予測して、何を準備して、そして何を失敗したのか。そ

CQRS（Command Query Responsibility Segregation、コマンド・クエリー責任分離）は、現代のアプリケーション設計において重要な役割を果たしているが、今回はよく議論になる一貫性・可用性・スケーラビリティについて書いてみよう。文章のみの説明なので、非常にイメージしづらいかもしれないけど。 一貫性と可用性の評価軸CQRSが一貫性と可用性を重要な評価軸として採用する理由は、CAP定理に基づいている。分散システムでは、ネットワークの分断や障害が発生した場合、一貫性と可用性の間でトレードオフが生じることが避けられない。CQRSはこのトレードオフを巧みに活用し、書き込みモデルで一貫性を、読み込みモデルで可用性を重視することで、最適なバランスを見つけることを目指している。 一貫性への影響イベントソーシングを伴わないシンプルなCQRSでは、非CQRSベースのシステムと同

どんな強力なツールでもそうであるように、CQRS（Command Query Responsibility Segregation）は無料で使えるわけではない。CQRSにはコスト（手間という意味）が伴うが、その利点も多い。 従来のアーキテクチャより複雑だと批判されることもあるCQRS/ES（Event Sourcing）だが、実際にはシンプルに実装できる部分もある。 CQRSにおけるモデルの分割CQRSではシステムを分割し、書き込みモデルと読み込みモデルを独立させる。例えば、ホテルの部屋を予約するシステムを考えると、部屋を予約する・宿泊人数を変更する・予約をキャンセルするなどの行為は書き込みモデル（集約ルート）に該当し、顧客別予約・ホテル別予約などの情報は読み込みモデルになる。この分割により、各オブジェクトはより単純化されるが、システム全体としての複雑さは増す。これは、CQRSにおける重要

こんなつぶやきをしたので、「モジュラーモノリス」について考える。特にモジュール性について考えてみる。 以下の主張は、実際のプロジェクト/プロダクトにとって最適かどうかは、具体的なビジネス要件、チームのスキルセット、運用上の制約など、多くの要因に依存する。アーキテクチャは常にトレードオフがあり、一つの解決策が全てのシナリオに適用できるわけではないので、その点を考慮して読んでほしい。 マイクロサービスではなくモジュラーモノリスを選択した場合には、しばしば以下の利点が強調される。 ネットワーク通信: モジュラーモノリスは、マイクロサービスと異なり、ネットワークを介した通信が発生しないため、ネットワーク遅延や断絶、通信エラーなどの問題が生じにくくなる データ整合性: 分散システムでは、データの整合性を保つために複雑なトランザクション管理やデータ同期が必要になるが、モジュラーモノリスでは同じデータベ

こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性

DDD関連の記事を紹介してみたい。 今回は、Vladikkさんの2018年の記事。タイトルは「DDDの基本を再考する」だが、内容としては「サブドメインの分類方法」について述べられている。 今回はこの記事を要約してみよう。（日本語での要約の許可をVladikkさんからもらっています） ※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします 前段に書かれている内容は基本的なものだ。 ドメインが事業領域を意味する サブドメインはさらに細分化された事業領域 サブドメインには種類がある。 汎用サブドメイン 一般的な問題を解決することで、コアドメインと支援サブドメインをサポートする 支援サブドメイン コアドメインをサポートするためのサブドメイン コアドメイン 重要なビジネス価値を提供する。競争優位性を持つか

AWS DevAx::connect ライブラリー シーズン1 / シーズン 2 のセッション動画と資料をごらんいただくことができます DevAx::connect にご参加いただいた皆様に、オンデマンドにてご利用いただける資料やセッション動画をご用意いたしました。ぜひご利用ください。※すべての資料の公開をお約束するものではございません。また、当ページに公開された資料および動画もセミナー当日のものと部分的に異なる場合がございます。予めご了承ください。 シーズン 1 を見る シーズン 2 を見る シーズン1「イベント駆動」 クラウドを活用したモダンなソフトウェア開発を進めていくにあたり、「イベント」をどのように扱うかが鍵になります。同期処理を前提とした考え方から離れ、イベント駆動をアーキテクチャに取り入れることでスケールしやすく、信頼性の高いシステムが構築できます。また、AWS のサービスも