認証基盤の統合をダウンタイムゼロで実現した6ヶ月に渡る準備
「HRMOS」シリーズでは多数存在する機能間での体験を統一するための様々な取り組みを続けています。 今回、HRMOSプロダクト本部プラットフォーム開発部では、ユーザー体験の向上とアーキテクチャ改善を目的として 「HRMOSタレントマネジメント」 内に複数あった認証基盤を統合しました。 本記事では、認証基盤統合に至った背景と、それをスピーディかつ安全に進めるために行ったプロセスや工夫をご紹介します。 構想から完遂までの約6ヶ月間の内、設計およびプロトタイプ作成に要した前半3ヶ月、実際に本番システムに段階的に変更を加えていった後半3ヶ月という大まかな流れに沿って説明します。 統合前の課題 「HRMOSタレントマネジメント」は内部的に「従業員データベース機能」を提供するモジュールと「評価管理」などの機能を提供するモジュールに分かれています。実はこれらのモジュールはそれぞれ個別の製品として同時期に
『Microservice Patterns』 まとめ - Qiita
今年10月に出版された『Microservices Patterns With examples in Java』という本を読んだ。面白かったので紹介したい。 はじめに 著者は、マイクロサービスパターンのサイト microservice.io を運営している Chris Richardson という人。Cloud Foundry の創設者でもあり、最近では Eventuate というマイクロサービス用のプラットフォームを提供してるらしい。コンサル経験も豊富らしく、本の中でもそこで得られた知見が盛り込まれている。 microservice.io でもマイクロサービスパターンはカタログ化されているが、この本ではサンプル事例で肉付けされて具体的に解説される。関連するトピックも豊富で勉強になる。 ここが面白い 問題領域のカタログとして役立つ 初心者が考えるマイクロサービスのイメージといえば、その人
サーバーレスが気になる開発者に捧ぐ「べき等性」ことはじめ 第一回〜べき等性 (冪等性/idempotency) ってなんだ!? - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
そもそも、べき等性とは、どういうことを言うのでしょうか ? これは「ある操作を 1 回行っても複数回行っても結果が同じである」ことをいう概念です。 例えば、注文処理を考えます。画面インターフェースで、注文確定 / 送信ボタンを押すという操作で二度三度押してしまうユーザーがいます。これで同じ内容の注文が複数回登録されてしまったら問題です。こういったケースでは、画面側で連続して押せないような実装を追加したり (①)、サーバー側で同じ注文の処理であることを認識して適切に一つの処理と判断するようなこと (②) が必要です。 この例では、画面側の制御を入れたほうが簡単なように見えます。しかし、現実には画面とサーバーとの間のネットワークの問題や画面以外からの HTTP コールなどを考えると、このような重複リクエストが起こってしまうという可能性はゼロではありません。 このようなものへの対処として、サーバ
「CQRSをやる」は「Event Sourcingをやる」とほぼ同義 リアクティブシステムとCQRSを反映した新アーキテクチャの設計思想
Chatwork に所属するエンジニアや外部ゲストなど、多分野のエキスパートたちの登壇を通して、エンジニア組織で取り組んでいる試みなどの知見を提供する「Chatwork Dev Day 」。ここで開発部テックリードの加藤氏が登壇。続いて、Event Sourcingと、新アーキテクチャの具体的な設計内容を紹介します。前回の記事はこちらから。 なぜEvent Sourcingなのか 加藤潤一氏（以下、加藤）：「なぜEvent Sourcingなのか」という話で、Event Sourcingの場合はどうなっているかというと、CRUDのステートソーシングは、最新のエンティティを上書きする考え方です。Event Sourcingは、そのとき発生した変更を追記していく考え方になります。 「状態はどういうふうに作るの？」という話ですが、イベントから状態を導出する考え方です。関数にイベントをapplyし
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog
はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ（Clean Architecture）です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは？ クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に
AWSを学ぶために最初に構築するアーキテクチャパターン５選 - log4ketancho
先日書いた AWS の勉強方法をまとめた記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります！業務で使う分にはサーバー何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
system-design-primer/README-ja.md at master · donnemartin/system-design-primer