どうも皆さんこんにちは. 鞍馬ぽめると申します, よろしくお願いいたします. はじめに この一年, まったりではありますが Akka の独学を進めていました. 今回は, 学んできてわかったことなどをまとめてみようと思います. なお, 間違いがあればご指摘いただけると嬉しいです. 独学で進めてきたため正しい理解ができていない可能性もあるため, ご指摘いただきより学びを深めたいと思っています m_ _m 学習用に用いたリポジトリは下記になります, 参考にしてみてください. CQRS + ES アクターモデルや akka の話をする前に, CQRS + ES という考えについて抑えておきます. ドメイン駆動設計における "集約" および "リポジトリ" と "一覧画面" の相性の悪さ ドメイン駆動設計を取り入れると, ひとつのトランザクション整合の単位として "集約" を用いることになり, 集約
はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに３年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか？を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の 2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類
この記事はニーリーアドベントカレンダー2024の9日目の記事 その2です。 こんにちは、ニーリーの佐古です。 現在プロダクト統括本部内のARCHチームというチームでテックリードとして開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 今回はその一例を https://clas-istyle.connpass.com/event/329922/ で発表した内容をもとにご紹介できればと思います。 過渡的設計とは プロダクトの成長の過程をざっくり書くと Minimum Viable Productの開発を行う Product Market Fitを狙う 業務の複雑さに対して開発がスケールする設計になる になりますが、この2と3の間を埋めるための設計になります。 世の書籍、あるいは勉強会においてベストプラクティスとなる設計は多々示されていますが、そのベストプラクティスより(Comp
この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
はじめに こんにちは、バックエンドエンジニアのおおたわらです。 弊社のプロダクトの一部に、顧客企業の行いたい調査（例えば、企業が顧客のニーズを理解し、最適なサービスを提供をするためのユーザー向け調査）に応じてアンケートを作成し、回答を集めることができる「アンケート機能」があります。 この機能はコンシューマ向けの大規模な調査（具体的にはメールやプッシュ通知等で数十万〜数百万人にアンケート回答を依頼するような調査）での利用も想定しており、大量アクセスに対応できることが求められます。更に、集めた回答に対し分析を実施し、すぐに結果を確認できることも求められます。 このためのアーキテクチャを構築したので、紹介します。 求められる要件 アーキテクチャに求められる主な要件は以下です。 大規模調査における大量のリクエスト（具体的には秒間 1000〜回答を想定）を処理できるスケーラビリティ 回答サーバーは可
累計2500万着電を支える大規模 電話自動応答サービスのアーキテクチャ / Architecture of a Large-Scale Automated Phone Response Service Supporting 25 Million Cumulative Calls
この記事はSmartBank Advent Calendar 2024 6日目の記事です。 昨日は kassy さんの「成長するスタートアップ労務の醍醐味と挑戦をUXリサーチャーが聞いてみた！」という記事でした。 はじめに サーバーサイドエンジニアの mokuo です。普段は、カード決済やあとばらいチャージに関連する機能の開発や運用を行っております。 本日は、サーバーサイドエンジニア向けの記事になります。 本記事でお話しすること システムには断続的に行われる一連の処理、というものがあります。この中で非同期処理を行うこともあるでしょう。 例) EC サイトにおける注文処理のワークフロー このような機能を開発・運用していると、以下のような課題に直面することがあります。 処理の流れが把握し辛い 変更を行うのが困難 データの整合性を担保するのが難しい しかし、適切に設計を行うことで、これらの課題を
このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ
前回好評だった「冪等性と非同期実行」の続編にあたる記事です。 gs2.hatenablog.com 私たちが提供している Game Server Services はバックエンドに Lambda + DynamoDB といったフルマネージドサービスを活用した、いわゆるサーバーレスアーキテクチャで実装されています。 前回の記事はデータの整合性を保ちつつ、いかに処理をするかに焦点を当ててお話ししました。 ゲームはデータの整合性に対する要件は金融システムほどではないものの、高い水準で求められます。 あわせて、ゲームは体験に対する要件の水準が高く、レスポンスタイムへの要件にも厳しいのが特徴となっています。 前回の記事でざっくりとGS2における消費処理と入手処理を軸とした、トランザクションアーキテクチャのお話をしました。 今回の記事では、このトランザクションの実行についてのパフォーマンスチューニング
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
この記事は、ニフティグループ Advent Calendar 2023 1日目の記事です。 前段の話 私が所属するプロジェクトでは、Design Docsでソフトウェアの設計や、目的、背景などを記述しており、継続的に更新しています。 Design Docsには、細かな設計方針や、その意図は明確に記述されていますが、読みやすさの観点から結論や重要なポイントのみを載せるようにしています。なので、粒度の細かい情報が失われてしまうということが起こってしまいます。 これでは新規参入者になぜ他の選択肢を選ばなかったか、なぜこの選択肢を選んだのかについて伝授されません。 未来の運用者は数ある選択肢からの導入理由や、決定の過程や議論した内容がわからないまま機能の追加や改修を行わなければなりません。 これが積み重なっていくと日々の運用のコストが膨らんでいき、運用したくないシステムになってしまい、技術的負債と
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、株式会社カオナビ Advent Calendar 2023の２日目です。 カオナビでは2022年9月からArchitectural Decision Record（以下ADR）を導入開始しました。本記事ではADRを導入し実際に一年間運用して見た経過をご報告しつつ、導入のポイントや注意点について紹介します。 ADRをなぜ導入したのか？ まずADRについて簡単に説明すると、「アーキテクチャー設計の記録をドキュメントとして残すこと」 です。Michael Nygardのブログ記事が初出のようです。 ソフトウェア開発を行っていく間に
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
http://martinfowler.com/bliki/SacrificialArchitecture.html 会議の席であなたは考えている。自分のチームが二年間かけて書いてきたコードのことを。そして決断に至る。いま打てる最善の手は、あのコードをすべて投げ捨てまったく新しいアーキテクチャを再構築することだ。死にゆくコード、それに費やした時間、自分が下し続けてきた判断。この決断は、あなたをどんな気持ちにするだろう？ 多くの人にとって、コードを捨てるのは失敗の証だ。ソフトウェア開発の探索的な性質を考えれば、わからない判断ではないかもしれない。けれど失敗には違いない。 ところが、いま書ける最良のコードは二年経ったら捨てるつもりのコードだということはよくある。 私たちは偉大なコードとして長命なソフトウェアを思い描くことが多い。私は 1980 年代に生まれたエディタでこの記事を書いている。ソフ
Towards the end of last year I attended a workshop with my colleagues in Thoughtworks to discuss the nature of “event-driven” applications. Over the last few years we've been building lots of systems that make a lot of use of events, and they've been often praised, and often damned. Our North American office organized a summit, and Thoughtworks senior developers from all over the world showed up t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
