مطالعه موردی ایجاد مقادیر قابل تنظیم

واژه نامه

مطالعه موردی

روزی روزگاری، فرآیندی در یک سیستم سازمانی یکپارچه وجود داشت.

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

@startuml Example Process
skinparam componentStyle rectangle

database "Product Table"

rectangle "Process" {
  [Admin UI]
  [Service]
  [DAO]
}

[Admin UI] --> Service: clicks to run
[API 1] -> [Service] : product\ncodes
[Service] -> [API 2] : products
[Service] -> [DAO] : product\ncodes
[Service] <-- [DAO] : products

[DAO] --> [Product Table] : database query
@enduml

نیاز جدید

می‌خواهیم کدهای محصول را به دسته‌ای تقسیم کنیم تا کوئری پایگاه داده خیلی بزرگ نباشد.

راه حل های پیشنهادی

بدیهی است که مقدار “تعداد محصولات در هر دسته” وجود خواهد داشت.

1. راه حل قابل تنظیم

یک مکتب فکری وجود دارد – “داده ها باید از منطق جدا شوند”.

پس از این فکر، مقدار باید از رابط کاربری Admin قابل تنظیم باشد و متعاقباً به DAO منتقل شود.

@startuml Example Process
skinparam componentStyle rectangle
skinparam defaultTextAlignment center

[Admin UI] as "Admin UI\n(with **value**)"
[Service]
[DAO]

[Admin UI] --> Service: value
[Service] --> [DAO] : value

@enduml

در این سناریو، چند اتفاق ممکن است رخ دهد:

1. یک کاربر سیستم به طور تصادفی مقدار را به یک مقدار غیر معقول به روز می کند و سیستم را می شکند.
2. یکی دیگر از الزامات این است که اطمینان حاصل شود که فقط توسعه دهندگان می توانند مقدار را از UI پیکربندی کنند.
3. با صدها پیکربندی، کاربر سیستم برای یافتن پیکربندی که بتواند واقعاً به‌روزرسانی شود، مشکل خواهد داشت.

از طرف دیگر، این رویکرد یک مزیت دارد:

• برای تنظیم مقدار، نیازی به اعمال تغییرات کد نداریم.

این رویکرد برای محیطی که در آن استقرار به ندرت انجام می شود مناسب است.

2. راه حل متغیر محیطی

با توجه به اینکه پیکربندی رو به کاربر نیست، روش دیگر ذخیره مقدار در متغیر محیطی است.

DAO مستقیماً مقدار را از متغیر محیطی بدست می آورد و از آن استفاده می کند.

@startuml Example Process
skinparam componentStyle rectangle
skinparam defaultTextAlignment center

[Admin UI]
[Service]
[DAO]
[Environment Variable]

[Admin UI] -.> Service
[Service] -.> [DAO]
[Environment Variable] -> DAO : value

@enduml

این رویکرد بهتری است زیرا Service و Cron Job نیازی به دانستن چیزی در مورد “تعداد محصولات در هر دسته” ندارند، که صرفاً یک مفهوم در منطق برنامه (برخلاف منطق تجاری) است.

در این رویکرد، چند چیز ممکن است رخ دهد:

1. کد به راحتی از محیط QA عبور می کند زیرا مقدار آن کمتر است.
2. کد در محیط Prod خراب می شود زیرا مقدار بالاتر است.
3. کار زیادی برای اطمینان از سازگاری محیط مورد نیاز است زیرا برخی از متغیرهای محیطی بین محیط ها متفاوت هستند، مانند URL های API.

3. راه حل سخت کدگذاری

مقدار فقط توسط DAO استفاده می شود.
مقدار نباید در سراسر محیط تغییر کند.
بنابراین، بهترین مکان برای آن در خود DAO است.

این نسخه کنترل می شود.
اگر کسی آن را تغییر دهد و سیستم را خراب کند، ما می دانیم.

نتیجه گیری

مقادیر قابل تنظیم به معنای نگهداری و ناسازگاری احتمالی است.

مقادیر قابل تنظیم را فقط در صورت نیاز واقعی ایجاد کنید.

ممنون که خواندید.
با خیال راحت نظرات خود را در نظرات به اشتراک بگذارید! 😉