マイクロサービスと設計原則 — 設計Night2018 登壇報告 #sekkei_n2018
マイクロサービスの設計に対して、どう設計原則を使うのか、という話をしました。本稿では、資料中のいくつかの点に補足したいと思います。 SRP (単一責任原則)単一責任原則原則について、提唱者である Robert C. Martin 氏が2014年にさらに考察している記事を紹介しました ( The Single Responsibility Principle )。 この中では、変更する理由は「人」であるということに強くフォーカスされています。この考え方は、マイクロサービスの現実の問題に非常にマッチするため、今回取り上げました。ただ、筆者個人の考えではつねにこの「人」にフォーカスするのが常に現実の問題を解決するのに役立つかは疑問で、場合によっては受け取り方には注意が必要かなと思います。単一責任原則は、この追記がなくても長く大事にされてきたものです。 マイクロサービスの統合マイクロサービスをどう
現代のフォローリスト - k4zy no blog
数日前の話、同僚からサポートissueの調査について相談を受けた。内容は「フォローリストが正しく表示されない(数人足りない)」というものだった。 最初にうちの会社の環境を紹介しておくと、メイン事業はモノリシックで巨大なrailsで書かれている。最近は機能や開発を担当するチームごとに切り崩してマイクロサービス化される事例も増えてきた。今回調査したフォローシステムを提供するアプリケーションもメインのrailsアプリケーションとは別に小さなrailsとして動いていた。 事前調査していた同僚から「DB上のソーシャルグラフは正常だった事」と「名前のないユーザーはフォローリストに表示されない事」を教えてもらった。今回のサポートissueに挙がってきた事例もユーザー名が無いことが原因の様で、それはシステム上意図してない挙動だった。 調査の手始めにユーザー名の管理について調べた。DBはアプリケーション毎に
マイクロサービスの境界を決める「DDD」とは？ (1/2)
マイクロソフトは、Microsoft Azureでシステムを構築するためのクラウド設計パターン、アプリケーションアーキテクチャガイド、リファレンスアーキテクチャを「Azureアーキテクチャセンター」のサイトで公開している。これらのパターンやガイドは、米マイクロソフトのAzureエンジニアが実際に検証した上で構成サービス/ソフトを選定し、ユーザーにとって失敗が少なく汎用性の高いベストプラクティスをまとめたもので、現在、32の設計パターンと100以上のガイドを公開している。 日本マイクロソフトが2018年3月30日に開催したクラウドアーキテクト/開発者向けセミナー「パターン＆プラクティスセミナー」に、Azureアーキテクチャセンターのクラウド設計パターンを作成している米マイクロソフト AzureCAT patterns & practicesチームの成本正史氏が登壇。自身が作成した「マイクロサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
