自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン - valid,invalid
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
公開日 2024/05/28更新日 2024/07/25注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女
全てのAPIをProtocol Buffersで管理する / Manage all APIs with Protocol Buffers
こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
![[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/15ef8078be3e3da04452bb61b549b0c2e924abfb/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwU2hvcGlmeSVFMyU4MSVBQiVFMyU4MSU4QSVFMyU4MSU5MSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MiVCOCVFMyU4MyVBNSVFMyU4MyVBOSVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQSVFMyU4MiVCOSVFMyU4MSVCOCVFMyU4MSVBRSVFNyVBNyVCQiVFOCVBMSU4QyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MGZmMDEzOTY1NDhkMDNjYThjYTVmMWFlZGZkMjNkN2U%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0a3lvd2EmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWZiZDJlOGIzYmQzMjk3ZDIxOTA4MjFhZDlkMGI0NTE2%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g6aOf44G544Ot44Kw%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3D82e163327a6dfc81be1ea9d983b95f9d)
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み｜ハイクラス転職・求人情報サイト AMBI（アンビ）
モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み 大規模なソフトウェア開発においてモノリシックかマイクロサービスかというアーキテクチャの議論がありますが、近年は第3の選択肢としてモジュラモノリスが話題になっています。いったんマイクロサービス化に舵を切りながら現在はモジュラモノリスに取り組むアソビューの考え方や進め方について、VPoEの兼平大資（disc99）さんによる寄稿です。 アソビューでは、現在の事業状況にマッチしていることや過去の経緯から、モジュラモノリスを中心としたアーキテクチャを採用しています。 今回は、なぜその選択をし、どのように実現しているかを紹介します。 記事の前半では、アソビューが提供する事業や、アーキテクチャに対する考え方、開発組織の歩みなどを説明します。 中盤以降は、アソビューにおけるモジュラモノリスへの取
モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの？」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで
AIに仕事を奪われないために、自分の発想を強化していかないといけない 服部佑樹氏（以下、服部）：次に行きたいと思います。「エンジニアとAIの関わり方」ですね。AIが登場したことによって、どういうかたちでエンジニアが変わっていくのか。概念としてはものすごく広いですが、みなさんもいろいろな観点の捉え方があると思っています。 組織としてどうするのかはその次の質問になりますが、あとはキャリアとしてとか、次のポジションをどうしようかなみたいなところも含めて、個人の観点なども含めて答えてもらえるといいんじゃないかなと思います。では黒崎さんからいいですか？ （スライドを示して）3番目の質問「エンジニアがAIと協力して新たなアイデアを生み出すための効果的なアプローチ」ですね。あとは2番も合わせていいかもしれませんが、アプローチと潜在的な力を引き出すためのスキルをどうやって学んでいったらいいと思いますか？
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって
こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
![[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dfb840670b1246203f99547145b4b7b27db28e26/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwU2hvcGlmeSVFMyU4MSVBQiVFMyU4MSU4QSVFMyU4MSU5MSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MiVCOCVFMyU4MyVBNSVFMyU4MyVBOSVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQSVFMyU4MiVCOSVFMyU4MSVCOCVFMyU4MSVBRSVFNyVBNyVCQiVFOCVBMSU4QyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NDUxODQ2MjU3YTEzNDMwMjQ4MDU3ODNmYzM3MjM3NGI%26mark-x%3D142%26mark-y%3D100%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0a3lvd2EmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWZiZDJlOGIzYmQzMjk3ZDIxOTA4MjFhZDlkMGI0NTE2%26blend-x%3D142%26blend-y%3D455%26blend-mode%3Dnormal%26txt64%3DaW4g6aOf44G544Ot44Kw%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D550%26s%3Dfb3a6bbe6d17db94858fcbdae8bc1b62)
RustでAPIを開発してみたら結構辛かった話
はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い！という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います
公開日 2024/06/19更新日 2024/07/25身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS
食べログのモジュラモノリス化戦略
「10年超えRails開発の振り返りと未来 - 持続可能な開発の具体策｣の発表資料です https://pieceofcake.connpass.com/event/324722/
私が働いているAniqueという会社では、1年前に全てのソフトウェアでTypescriptを採用することにしました。私たちが開発している進撃の巨人のNFTサービス “Attack on Titan: Legacy” でも採用しています。 TypescriptではNestJSという素晴らしいAPIフレームワークを利用することができ、生産性高く開発を続けることができます。また、私たちはフロントエンドでNext.jsを利用しています。言語レベルでのコンテキストスイッチを抑えることで、一人のエンジニアがフロントエンドとバックエンドのどちらもの機能を開発する環境が作れました。 しかし、Nodeならではの作法や設計について、Web上にはたくさんの情報があるものの、あまりにも情報が多すぎて、まとまったプラクティスになかなか出会うことができませんでした。そのため、最初はチーム内での共通認識を作るのに苦労し
GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか - はてなニュース
社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステム「カオナビ」を提供する株式会社カオナビでは、SaaS移行にあわせてクラウドを全面的に採用し、インフラの自動化などにAWSのマネージドサービスを積極活用しています。とはいえ10年近い運用で、サービス開発におけるシステムのモノリス化が課題となってきました。 こういった全社的な課題は、2020年からCTOを務める松下雅和（@matsukaz）さんを中心にCTO室で対応しています。モノリスなシステムは、全体のモジュラモノリス化を前提に、とくにボトルネックとなる検索処理を非同期の基盤サービスとして切り出しています。 この検索基盤の設計と実装を通して、カオナビはシステムのアーキテクチャ改善をどのように進めようとしているのか。非同期である必要性や、デプロイの工夫、開発組織の文化まで含めて、CTO室の千葉峻秀さんとインフラグループの
ソースコードのハッシュ値を利用したCIの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintoneチームの川向です。 ソースコードハッシュ値計算ツールであるsverを導入してCIの高速化を行ったので、その紹介をさせてください。 この仕組みにより、通常は1時間かかるCIの実行時間が最善のケースでは20分程度に短縮可能になりました。 導入前の課題 解決方法の検討 sverを使ったテストのスキップによるCI高速化 kintoneでのsverの利用方法 sver設定ファイルの書き方 キャシュの保存先(GitHub Actions Cache、Amazon S3) sverを使ったジョブの書き方 sver情報生成ジョブ: ハッシュ生成とキャッシュの存在確認 ビルドジョブ: 依存ファイル以外に依存しないことの確認 テストジョブ: ジョブ成功後にキャッシュ保存 下流ジョブのifの書き方 結果 課題と今後の展開 まとめ 導入前の課題 kintoneのCIの大まかな構成は以下の
はじめに マイクロサービスの開発では、サービスが増え続けるバックエンドに対して、フロントエンドは接続先が増えるため、開発効率を下げてしまいます。その対策として、さまざまな設計パターンが存在します。 弊社の開発ではGraphQL Gatewayを用いていますが、そこに至るまでや周辺の技術/アーキテクチャを解説します。 マイクロサービスとフロントエンド マイクロサービスを採用する場合、フロントエンド（ウェブアプリケーション、モバイルアプリケーションなど）は複数のサービスとの連携が必要になることが多いです。各マイクロサービスは通常、API（REST、gRPCなど）を提供し、フロントエンドはこれらのAPIを通じてデータの取得や操作を行います。 API Gateway API Gatewayは、フロントエンドとマイクロサービス間の中間に位置するコンポーネントとして機能し、マイクロサービスアーキテクチ
マイクロサービスにおけるAZ間通信のコスト大幅削減した話 with Istio Locality Load Balancing - Gunosy Tech Blog
広告技術部のUT@mocyutoです。 大幅コスト削減シリーズ第二弾です。 前回はこちら tech.gunosy.io 今回はアベイラビリティゾーン（AZ）間通信のコストをIstioのlocality load balancingを使って削減した話になります。 概要 Istioとは どのようにコスト削減したか まとめ 概要 みなさんはマイクロサービスを導入しているでしょうか？ 最近はモジュラモノリスが流行り始めている雰囲気を感じてきていますが、弊社の広告配信サーバは以下のようなマイクロサービス化された設計（と言っても2つのサービスしかないのですが）になっています。 構成図 一般的にクラウドプロバイダ上で構築している場合、耐障害性を高めるために複数AZ、複数リージョンに分散させることが基本になるかと思います。 弊社では、単一リージョン複数AZに分散させて稼働しています。 リージョン間の通信に
フロントエンドの消失 - または戦争が激しくなる話
React Server Components に感じたフロントエンドの消失という記事に端を発する一連の議論だが、実際この記事で書かれていることはそうだろうなと思う。話の流れとして誤ってる部分はないと思うし同意する。 この記事ではフロントエンドエンジニアとして、この件についての僕の見解を書く。もちろんフロントエンド（とは？）の総意ではない。 元記事と重複する部分多いが、そこは同じ問題を取り扱う以上避けて通れないため、ご容赦いただきたい。 同じ領域を取り扱ってる以上、開発戦争は激しくなる 様々な理由によりユニバーサルが求められている ※この記事でいう「戦争」とは、お互いの領域を食い合う開発が、活発化することを「戦争」と称しているだけです。それ以上の意図は全くございません 領域がかぶっている 最近のフロントエンド系ユニバーサルエコシステムは、たしかに PHP や Rails の領分を侵そうとし
こんにちは、プラットフォームチーム所属のまこたすです。 昨今、様々な場で「モジュラーモノリスを導入した」という話を目にするようになってきました。弊社でも昨年からモジュラーモノリスの試験導入を進めており、社内でノウハウが徐々に溜まってきたため、今回 技術ブログ で なぜ導入したのかと知見の共有 をさせていただけたらと思います。 想定読者 モノリスなアプリケーションの分割を検討している Railsへのモジュラーモノリスの導入を検討している 話さないこと チーム体制がどうあるべきかという観点の話 以下アーキテクチャについての詳細 モノリスアーキテクチャ モジュラーアーキテクチャ 背景 今回「モジュラーモノリスを導入した」というタイトルですが、最初に検討・導入に至るまでの背景について触れたいと思います。 hacomonoという組織・サービスの成長 hacomonoというサービスはリリースから現在に
深いドメインと統合型経営プラットフォームを支えるモジュラモノリスの事例 / Modular Monolith That Support Deep Domains And Integrated Management Platform
freeeにおけるモジュラモノリスの事例を大規模プロダクトから新規プロダクトまで紹介します。
Spring Modulith でモジュラモノリスなアプリの構造を検証してみた - Taste of Tech Topics
アクロクエスト アドベントカレンダー 12月9日 の記事です。 普段は Java, Python でバックエンドの開発をしている大塚優斗です😃 最近は Spring フレームワークのメジャーアップデートなどで盛り上がっていますね！ 10月にこんな記事を見かけて、Spring Modulith がとても気になっていたので、手元で試したことを書いていきます✍️ Spring Modulith とは Spring Modulith でできること 0. Spring Modulith でのパッケージの扱いについて 1. モジュール構造の検証 循環参照の検知 別モジュールへのアクセス違反の検知 2. モジュールに閉じた結合テスト 単一のアプリケーションモジュールで結合テストができること Bootstrap モードによって、結合テスト時に他モジュールの Bean 生成ができること 3. イベントによ
LINE株式会社 古田 大志 京都開発室 / 出前館マーチャント部 クーポンサービス チームリード 2023.9.12「モジュラモノリス徹底解剖vol.2〜実践者から学ぶLunch LT〜」の登壇資料です https://findy.connpass.com/event/293748/
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「働きやすく、成長し続けられるエンジニア組織を目指して 」をテーマに株式会社カオナビの松下氏が登壇。ここからは、CTOに就任して行った取り組みと、CTO室の設立について話します。前回はこちらから。 CTOに就任して行った3つの組織的な取り組み 松下雅和氏：ここからはCTOとして組織全体の話をしようと思います。当時「ニューノーマル時代のカオナビへ」ということで、オフィスの移転を行っています。カオナビでは、働き方を選択するのは企業ではなく、社員がするべきだと考えています。 出社は義務ではなく、自由に出社しても自宅でもいい。出社するなら居心地のいい環境を提供するのが企業の義務だと考えているので、すごくいい環境のオフィスを提供してもらった記憶があります。 働き方では、ハイブリッド勤
健康第一！MetricKitで始めるアプリの健康診断 / App Health Checkups Starting with MetricKit
Sansan Technical Viewは「挑戦」をテーマにSansanエンジニア達の開発における取り組みや知見を発表するイベント。Bill One事業部のソフトウェアエンジニアである加藤氏がマイクロサービスへの取り組みを紹介しました。発表資料はこちら。 Bill Oneでのマイクロサービスの取り組み 加藤耕太氏：こんにちは。加藤です。今日は『新規事業でもマイクロサービスに挑戦する』というタイトルでお話しします。マイクロサービスアーキテクチャについてご存知の方は、新規サービスをマイクロサービスで作るのはアンチパターンである、という話を聞いたことがあるかもしれません。 チームが小さいにもかかわらず流行りに乗ってマイクロサービスに分割して作ってみたものの、開発の効率が落ちるだけでしたとか、独立してデプロイできない分散モノリスができあがってしまいました、のような失敗談を聞くことがあります。 新
@hokaccha です。こんにちは。最近は主にプロダクト基盤チームで組織的な開発生産性の改善に取り組んでいます。この記事では開発生産性を改善の一環として、現在取り組んでいるシステムアーキテクチャの改善や技術的負債の返却の取り組みについて紹介します。 なぜアーキテクチャを改善するのか 最初に、なぜ我々がアーキテクチャ改善に取り組んでいるかの背景について説明します。 最終的にやりたいことは開発生産性を改善することにより、事業の成長速度を最大化することです。アーキテクチャの改善はそのための手段の一つであり、他にも開発プロセスの改善や開発組織の最適化など、開発生産性の改善のために並行しておこなっている施策は多岐にわたります。 ではアーキテクチャの改善がどう開発生産性に影響を与えるかという話ですが、これについては Martin Fowler の Design Payoff Line の図を引用しま
『設計ナイト2024【オフライン】 - connpass』に参加してきたのでそのメモです。 各発表の感想 ※資料スライドは見つけたら貼ります。 ロジックから状態を分離する技術 今日の登壇資料です。 ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyhttps://t.co/XxBNAYiKXS #sekkeinight— わいとん (@ytnobody) 2024年6月14日 感想 純粋関数の話を基軸にいかに容易にしていくのか、という話 入力から必然的に出力が決まるロジック類をDomainとしておこうという発想はよかった 純粋関数の構成デザインパターンの分け方すごくいいなぁと思ったのと、このあたりの話を提唱している人いないのがびっくり 関連リンク 純粋関数とは - 意味をわかりやすく - IT用語辞典 e-Words Flux パターンが解決した課題 -
今年もRubyKaigiが始まりましたね！noteはrubyスポンサーとして協賛しています。三重の会場にきている方は、ぜひnoteのブースにも足を運びください。 さて、noteはRuby on Railsを用いたwebサービスとして2014年にリリースされました。現在でも継続してRailsのコードベースを利用しています。 しかし、多くの機能がリリースされ、開発者も増えたため、モノリスの巨大化が進んでおり、開発効率に影響が出始めていました。 今回はそれらの問題を解消するために、noteが継続的に取り組んでいる・取り組んできたバックエンドの改善プロセスについて説明していきます。 モジュールでサービスを構成するモノリスは大きくなるとメンテナンスが難しくなります。Railsは、MVCの各層に全てのドメインがフラットに並び、レイヤごと・レイヤ間の結合度が高くなる設計思想で、巨大モノリス化への対処が難
この記事はUbie Engineering Advent Calendar 2023の一日目です。よろしくお願いします。 背景 ユビーのシステムは言語が多様化してきたことにより、認知負荷の増加や運用負荷の増加、開発支援に仕組みづくりかけるコストの増加などの問題が発生していました。この課題を解決するためにNode.jsとGoに言語を絞っていくという意思決定をしたのが昨年です。これについては以下の記事で詳しく解説しています。 ちょうど去年のアドベントカレンダーの記事なのでこれから一年経ちました。ここでは以下のように述べられています。 Server-Side Kotlin などで書かれている既存サービスを、この技術選定の文脈でリプレイスすることは今のところ考えていません。 ただし、多くの既存サービスはドメインたくさん抱えすぎ問題があったり、色々とレガシーだったりして、徐々に別サービスに切り出して
モジュラモノリスで表現する複雑なドメイン領域と境界 https://speakerdeck.com/showmant/expressing-complex-domain-regions-and-boundaries-with-modular-monoliths PofEAAで考えるSaaSバ…
SmartHR、LayerX のアーキテクチャをそれぞれ話す「マイクロサービス？モノリス？2 社のアーキテクチャから見るPros/Cons」。ここで株式会社SmartHRのすがわら氏が登壇。「SmartHR」における3つの「大きくてつらい」問題と、その解決に向けた社内の取り組みを紹介します。 自己紹介 すがわらまさのり氏：本日はSaaSのアーキテクチャについて、私の所属企業であるSmartHRの事例を紹介していければと思います。「SmartHR」は人事労務に関する処理をペーパーレス化できたり、人事データの一括・一元管理を行えるサービスを提供するSaaSです。 はじめに、簡単な自己紹介をさせてください。私はすがわらと言います。SmartHRに2年くらい在籍しています。職種はプロダクトエンジニアで、いわゆる開発をするエンジニアです。2021年の7月からチーフという役割をもらっていて、チームのマ
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
モダンでフルサイクルな金融プロダクト開発 / Modern full-cycle financial product development
深いドメインと統合型経営プラットフォームを支えるモジュラモノリスの事例 / Modular Monolith That Support Deep Domains And Integrated Management Platform
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
モノリスとマイクロサービスを経てモジュラモノリスを導入した実践事例
[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
BASE大規模リアーキテクチャリング / base_rearchitecturing
リアクティブは難しいが役に立つ - kubell Creator's Note
React Server Componentsに感じたフロントエンドの消失
今後のスキルセットには必ず「AIを使いこなす」が組み込まれる GitHub CopilotとChatGPTの登場から考え直す、AIとの関わり方
マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
マイクロサービス間通信における認証認可およびアクセス制御
[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳
GraphQL Gatewayはフロントエンド開発を幸せにする
モノリスなRailsにモジュラーモノリスを導入した話 - hacomono TECH BLOG
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
エンジニア組織のロール再定義、横断で動くためのCTO室設立… 組織改善にはボトムアップとトップダウンのどちらも大切
モノリシックRailsアプリケーションを モジュラモノリスへ移行している noteの事例
Sansanの「Bill One」がマイクロサービス化に挑戦した理由 ある程度方向性が見えてきてからサービスは分割すべき
ユビーにおけるシステムアーキテクチャを改善するための取り組み
『設計ナイト2024』に行ってきたよメモ - コード日進月歩
Railsプロジェクトをモジュール分割して見通しをよくする｜こんぴゅ
Node.jsで作るモジュラモノリスの設計と技術選定
Clean ArchitectureとEffで変更に強いAPIを設計する
コードベースがでかい・テーブルの規模がでかい・エンジニア人数がでかい SmartHRにおける“でかい三銃士”解決のための取り組み
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog