リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
副作用を最小限に抑えるために必要なこと - かとじゅんの技術日誌
若干、難しい話ですが、設計力を上げたいプログラマ向けなエントリ。私も道半ばです。一緒に考えていただければ幸いです。 堅牢なアプリケーションを実現する上で「副作用を最小限に抑える」という設計思想は、非常に重要な示唆を含んでいます。 その「副作用」とは、そもそもどんな定義なのでしょうか。 DDDでは"side effect"と定義していて、以下のように解説されています。 Domain-Driven Design: Tackling Complexity in the Heart of Software: Evans, Eric: 8601300201665: Amazon.com: Books エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon P250より引用 In standard English, the term side effect implies
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約
新卒2年目が鍛えられたコードレビュー道場 #jjug_ccc #ccc_l3
Blog