کد بررسی‌ها که قبلاً شبیه یک آشفتگی بود، با افزودن هر ویژگی جدید، بیشتر و بیشتر متورم شد. تغییر یک بررسی گاهی اوقات روی بررسی‌های دیگر تأثیر می‌گذاشت. بدتر از همه، وقتی سعی کردید بررسی‌ها را برای محافظت از سایر اجزای سیستم استفاده مجدد کنید، مجبور بودید برخی از کدها را تکرار کنید زیرا آن اجزا به برخی از بررسی‌ها نیاز داشتند، اما نه همه آن‌ها.

سیستم بسیار دشوار شد و نگهداری آن گران شد. مدتی با کد دست و پنجه نرم کردید تا اینکه یک روز تصمیم گرفتید کل آن را بازسازی کنید.

مانند بسیاری از الگوهای طراحی رفتاری، زنجیره مسئولیت به تبدیل رفتارهای خاص به اشیاء مستقل به نام پردازش‌گرها متکی است. در مورد ما، هر بررسی باید به کلاس جداگانه‌ای با یک متد واحد که بررسی را انجام می‌دهد، استخراج شود. درخواست، همراه با داده‌های آن، به عنوان یک آرگومان به این متد منتقل می‌شود.

الگو پیشنهاد می‌کند که این پردازش‌گرها را به صورت زنجیره‌ای به هم متصل کنید. هر پردازش‌گر مرتبط یک فیلد برای ذخیره مرجع به پردازش‌گر بعدی در زنجیره دارد. علاوه بر پردازش یک درخواست، پردازش‌گرها درخواست را در امتداد زنجیره منتقل می‌کنند. درخواست در امتداد زنجیره سفر می‌کند تا همه پردازش‌گرها فرصت پردازش آن را داشته باشند.

بهترین قسمت این است که یک پردازش‌گر می‌تواند تصمیم بگیرد که درخواست را به پایین زنجیره منتقل نکند و به طور مؤثر هرگونه پردازش بعدی را متوقف کند.

در مثال ما با سیستم‌های سفارش، یک پردازش‌گر پردازش را انجام می‌دهد و سپس تصمیم می‌گیرد که آیا درخواست را به پایین زنجیره منتقل کند یا خیر. با فرض اینکه درخواست حاوی داده‌های صحیح است، تمام پردازش‌گرها می‌توانند رفتار اصلی خود را اجرا کنند، چه بررسی‌های تأیید هویت باشند یا کش کردن.