DDDネタです。 DDD Community-JPのDiscordで「複数の集約（Aggregate）をまたいで整合性をどう担保するのが良いのか？」という話がされていました。 この話を読んでいて、 yoskhdia.hatenablog.com でもサラッと触れた「トランザクション」をもう少し掘ってみようかなと思い立ったので書いてみるエントリです。 先の記事では次のように書きました。 実業務、ドメインを見れば、本当にまとめて処理しなきゃいけないものは、結構少ないはずです。 働く人たちは、どういう会話をしているのか、仕事の単位は何なのか、によってトランザクションを設計することが、メッセージングシステムを考えるうえで有用だと考えています。 「トランザクション」という言葉は、開発者にとっていくつかの意味を持ちます。 ここでは、 DB操作のトランザクション（以下、DBトランザクション） 業務のうえ

JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす