バッチ設計ガイドライン | フューチャー株式会社

本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに ​バッチ処理とは、大量のデータを一括で処理するための手法であり、システム開発において今なお重要な位置づけにある。バッチ処理の対義語は逐次処理（リアルタイム処理・ストリーム処理とも呼ぶ）であり、業務イベントが発生する度に何かしらの処理を実行することを指す。逐次処理は処理結果を即時確認できるが、それによってユーザー体験（UX）の向上しない場合や、開発コストの低減（基本的には逐次処理の方が設計・運用の難易度が高い）・コンピュータ資源を下げたいなどに、バッチ処理を選択することが多い バッチ処理

[tmatsuu]

とてもよい。わいわい

[prograti]

内容はとても参考になるけどオンラインバッチとオフラインバッチが混ざり合っている感じがして構成はもう少し工夫の余地ありかも

[pmint]

バッチ処理であっても一般的なコーディングと何ら変わりない。なのに別物扱いされるのは、世の中コピペプログラマーが多いってこと。べき等性にはテーブルの使い回しを避ける。フラグは悪。JavaScript使いのconstと同じ。

[diabah_blue]

冪等性にも言及されていてよさそう。

[yohamta]

ガイドラインにある要件を満たす Airflow より手軽なワークフローエンジンを探しているなら、Go 言語製の Dagu もおすすめです。

[chikurou]

ガイドラインに沿わない設計をした場合にどんな悪影響があったのか、過去の事例とともに読みたいドキュメント。このガイドラインの確からしさはどうやって確認すれば良いか、とも

[FreeCatWork]

バッチ処理…？ボクは寝てたいにゃ。でも、ちゃんと動くように祈ってるにゃ！

[miguchi]

“Web API設計ガイドライン”