شروع پروژه معمولاً با اجماع همراه است. تیم EF Core را می‌شناسد، سرعت توسعه مهم است، مدل دامنه واضح است و فشار تحویل وجود دارد. در چنین شرایطی، انتخاب EF Core نه عجیب است و نه شتاب‌زده؛ برای بسیاری از تیم‌ها تصمیمی طبیعی و قابل دفاع به حساب می‌آید.

مسئله معمولاً از جایی شروع نمی‌شود که این تصمیم اشتباه بوده باشد؛ از جایی شروع می‌شود که فرض می‌کنیم این تصمیم همیشه به همان شکل معتبر باقی می‌ماند.

سیستم‌ها اغلب با بحران هشدار نمی‌دهند. نشانه‌ها معمولاً تدریجی و کم‌صدا هستند.

در این مرحله، تمرکز اغلب روی اصلاح نشانه‌هاست، نه بازنگری تصمیم‌ها. تلاش می‌شود سیستم به وضعیت قبل برگردد، بدون اینکه پرسیده شود آیا هنوز همان سیستم قبلی است یا نه.

در عملیات‌های write واقعی، معمولاً قبل از اعمال تغییر، وضعیت فعلی خوانده می‌شود، محدودیت‌ها بررسی می‌شوند، تصمیم بیزنسی گرفته می‌شود و سپس write نهایی انجام می‌شود.

در این نقطه، سؤال اصلی اغلب این نیست که EF Core مناسب است یا نه. سؤال‌ها بیشتر درباره‌ی شفافیت رفتار سیستم هستند.

اگر پاسخ این سؤال‌ها روشن باشد، EF Core همچنان می‌تواند انتخاب مناسبی باقی بماند. اگر نه، این الزاماً به معنی انتخاب اشتباه ابزار نیست؛ اغلب نشانه‌ی این است که نحوه‌ی استفاده نیاز به بازنگری دارد.

معمولاً مرحله‌ای می‌رسد که بحث‌های معماری کمتر می‌شوند، tuning بیشتر از طراحی وقت می‌گیرد و تغییرات ساده با احتیاط غیرعادی انجام می‌شوند.

سیستم هنوز کار می‌کند، اما اعتماد ذهنی تیم به پیش‌بینی رفتار آن کمتر شده است. این وضعیت لزوماً شکست نیست؛ اغلب نشانه‌ی عبور سیستم از مرحله‌ای است که تصمیم‌های اولیه بدون بازنگری کافی بوده‌اند.

در تجربه‌ی بسیاری از تیم‌ها، بازنگری معمولاً تدریجی اتفاق می‌افتد. بعضی مسیرها شفاف‌تر می‌شوند، بعضی readها کنترل‌شده‌تر طراحی می‌شوند و بخش‌هایی بدون تغییر باقی می‌مانند.

نه ابزار حذف می‌شود و نه تصمیم‌های قبلی بی‌اعتبار اعلام می‌شوند؛ فقط فرض‌ها دوباره دیده می‌شوند.

بسیاری از چالش‌هایی که به ابزار نسبت داده می‌شوند، در واقع نشانه‌ی این هستند که سیستم وارد مرحله‌ای شده که تصمیم‌های اولیه نیاز به بازنگری دارند، نه الزاماً جایگزینی.

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