本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか？　～関心の分離と疎結合～」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか？」ということを、理解いただくのが本日のゴールとなります。 というわけで本

はじめにアーキテクチャを突き詰める Online Conferenceの公募LT選手権で、「やってみてわかった クリーンアーキテクチャの勘所」というタイトルでトークをしました。LTということで、具体的な技術面でのメリットや、改善すべき点などについて話しました。（登壇資料はこちら） 本稿では、少し視座を上げて、結局クリーンアーキテクチャ（以下、CAと表記）は一体何なのかということについて、現在の筆者の考えを整理したいと思います。 あの図話が手っ取り早いので、例の同心円の図をまずは引用します。 図の出典: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.htmlCAでは、レイヤー（層）間の依存関係は同心円の外側から内側へ向く方向のみ許容されます。内側にあるコードは上位レベルの方針を表すものであり、外

20240522 Findy主催「アーキテクチャを突き詰める」登壇資料 イベントストーミング、ドメインモデリング、CQRS+Event Sourcing

スライド概要 Findyさんのイベント「アーキテクチャを突き詰める Online Conference」のLT登壇資料です。

https://www.reddit.com/r/LocalLLaMA/comments/1cvw3s5/my_personal_guide_for_developing_software_with_ai/?rdt=40405 はじめに 私は個人プロジェクトでコードを書く際、特に自動化のためのものを書く際には、AI を活用しています。この点について、人によって意見が分かれるようです。同じように AI を使っている人もいれば、AI が良いコードを書くことは不可能だと考える人もいます。私の分野の専門家の間でも同様の考え方に遭遇し、AI の使い方が人によって異なるのかもしれないと気づきました。 私自身のバックグラウンドですが、私は開発マネージャーであり、業界で長年の経験を積み、大学院でもソフトウェア開発を学んできました。ですので、このガイドは素人ではなく、大規模システムの構築と運用に関するかなり

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

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

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

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）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性

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