gRPCで分断されたモノリスを段階的にモジュラーモノリスに移行する - 株式会社ヘンリー エンジニアブログ
こんにちは。株式会社ヘンリーでエンジニアをしているagatanです。 私たちが開発する電子カルテ・医事会計システム「Henry」は、非常に巨大な単一のプロダクトです。そして、その性質上、明確なドメイン境界を見出すことが難しいという特性を持っています。この「巨大で複雑なプロダクトを、いかにして組織的に開発し続けるか」という問いに開発チームは長年向き合ってきました。 最近、この大きな問いに対する新たな一手として、かつて2つのgRPCサービスとして分割されていたバックエンドを、段階的に「1プロセスのモジュラーモノリス」へと移行させるプロジェクトが進捗しています。 今回は、その移行の過程についてお話しします。 第一歩: モノレポ化 移行への大きな第一歩目は、2年前に遡ります。当時、第一歩として踏み切った「モノレポ化」については、過去のブログでも紹介されています。 dev.henry.jp この記事
Software Architecture in an AI-Driven World
2025年の新卒研修の資料です。
クロスファンクショナルチームになるための壁崩しのお作法 #scrumniigata | ドクセル
うちは特殊だから、と距離を取ってきた利用可能なインクリメントとちゃんと向き合ったら成長できたチームの話
アプリケーションアーキテクチャをいい感じに検証し続けたい話 - CADDi Tech Blog
こんにちは、Drawer Growthグループ ソフトウェアエンジニアの内田(id:usadamasa, @usadamasa)です。弊社ではApache Icebergの活用*1とともに、一部のアプリケーションにJavaを導入しています。今回は、システムアーキテクチャから一段レイヤを下げてアプリケーションレベルのお話しをしたいと思います。 アプリケーションアーキテクチャの設計と運用課題 アプリケーション開発において、私たちエンジニアは通常、パッケージ構成やレイヤの依存関係、ロギングなどの観点からアーキテクチャを設計します。 しかし、実装との不整合やチーム内での共通認識が不十分なまま進むと、品質課題として潜在化し、やがて本番障害や開発者の疲弊といった形で問題に発展します。また、DevinやClineなどのAIエージェントに適切に実装してもらうにはプロンプトやドキュメントで設計を伝える必要が
一歩ずつ成長しながら進める ZOZOの基幹システムリプレイス/Growing Stap by Stap ZOZO BackOffice System Replacement
ファインディ株式会社が主催した「アーキテクチャ選定の事例と学び ～モノリス、マイクロサービス、モジュラーモノリスの共生と最適化～」というイベントでの発表スライドです。
メンテナンス画面の表示方法いろいろ | 外道父の匠
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
コスト最適化by オーナーシップ ～俺たちはQuick Winで満足しない～
第47回 Tokyo JAZUG Night ※リンクを効かせるにはダウンロードしてください
Feature Flag Deep Dive
チーム勉強会で Feature Flag とトランクベース開発の話をしました （追加訂正と書かれているスライドは、勉強会後議論した結果を反映したものです）
「Design It!」を読んだ - Magnolia Tech
副題にある通り「プログラマのためのアーキテクティング入門」ということで、どうやってシステムのアーキテクチャを設計していくか？という課題に対して向き合うための方法を示してくれる本です。 とはいえ、所謂アーキテクチャカタログ集ではないので、即効性の有る内容ではなく、ゼロベースでアーキテクチャを決めていくための思考のステップを示してくれる内容なので、具体的なアーキテクチャにつながる技術要素は、ここに示された内容を元に情報収集し、判断し、決めていくしかないですね。 第Ⅰ部 ソフトウェアアーキテクチャ入門 1章 ソフトウェアアーキテクトになる 2章 デザイン思考の基礎 第Ⅱ部 アーキテクチャ設計の基礎 3章 デザイン戦略を立てる 4章 ステークホルダーに共感する 5章 アーキテクチャ上重要な要求を掘り下げる 6章 アーキテクチャを選ぶ（君がアーキテクチャに選ばれる前に） 7章 パターンで土台を作る
PdM/EMが気づくべき「技術負債」の異変〜予測精度の幅で捉える〜
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 技術負債とは、現場のエンジニアが感じる理想と現実との乖離のことでリファクタリングやリプレイスはそれを少しでも差分を埋めることである。（その差分を本当に埋めることができるかはエンジニアのスキルとシステムの複雑性による） そうなったときに、どこに一番その予兆ができるかというと一番わかり易いのは工数の予測精度の幅があると仮定する。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていること
開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か？ 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ
2024/07/13 大吉祥寺.pm 20分レギュラートーク 登壇資料
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Level up your developer experience: Five practical strategies for engineering teams
The Model Context Protocol: Getting beneath the hype
From User-Friendly to AI-Friendly: Designing Digital Experiences for Humans and Intelligent Agents
https://blogs.oracle.com/otnjp/post/unit-test-your-architecture-with-archunit-ja
高品質と高スピードを両立させるテストアプローチ/Test Approach that Improves Quality and Agility Together
トヨタ生産方式(TPS)入門
フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy
