اگه دنبال کتاب تخصصی میگشتید
این یکی از بهترین سایت های ممکنه
فرانت سایتش به شدت داغونه😕
ولی از نظر عملکرد خیلی خوبه
مخزن کتاباهاش از z lib بیشتره🥳
همینطور نیاز به ورود هم نداره 🥰
و بر اساس ویژگی های بیشتری می‌توانید جست و جو و مرتب سازی کنید🔥
با پهپ زدنش😒🤢
https://libgen.is/
@Code_Crafters
این یکی از بهترین سایت های ممکنه
فرانت سایتش به شدت داغونه😕
ولی از نظر عملکرد خیلی خوبه
مخزن کتاباهاش از z lib بیشتره🥳
همینطور نیاز به ورود هم نداره 🥰
و بر اساس ویژگی های بیشتری می‌توانید جست و جو و مرتب سازی کنید🔥
https://libgen.is/
@Code_Crafters
👍11❤2👎2😁2👏1
مقابله با منطق تجاری پیچیده
به مباحث منطق تجاری رسیدین قلب تپنده هر سیستمی در پست‌های قبلی دو الگوی ساده اسکریپت و الگوی فعال رو بررسی کردیم و در ادامه مباحث منطق تجاری، الگوی دامنه پیچیده رو بررسی میکنیم، الگوی «مدل دامنه» مجموع‌ها و اشیا ارزش بلوک‌های سازنده آن است
الگوی مدل دامنه برای مقابله با موارد منطق تجاری پیچیده در نظر گرفته شده است.
در اینجا، به‌جای رابطهای CRUD، با انتقال‌های حالت پیچیده، قوانین تجاری، و متغیرها سروکار داریم: قوانینی که همیشه باید محافظت شوند. برای مثال یک سیستم مدیریت پیام بصورت ارزش گذاری روی پیام‌هارو در نظر بگیرید(یک سیستم help desk) که شامل یکسری الزامات هست که مانند یک شبکه درهم تنیده از وابستگی‌ها قوانینی که همگی بر چرخه حیات سیستم تاثیر گذار است، تلاش برای پیاده سازی این منطق با استفاده از اشیا رکورد فعال تکرار منطق را میسر میکند و با اجرای نادرست برخی قوانین تجاری، وضعیت سیستم را خراب میکند
پیاده‌سازی:
مدل دامنه یک مدل شی از دامنه است که هم رفتار و هم داده‌ها را در بر می‌گیرد. الگوهای تاکتیکی DDD - مجموع‌ها، اشیاء ارزش، رویدادهای دامنه و خدمات دامنه - بلوک‌های سازنده چنین مدل شی هستند. همه این الگوها منطق تجاری را در اولویت قرار می دهند
پیچیدگی:
منطق تحاری دامنه ذاتا پیچیده است، بنابراین در مدلسازی آن نباید پیچیدگی اضافی ایجاد کرد. مدل نباید درگیر نگرانی‌های زیرساختی و موارد مربوط به تکنولوژی باشد(مثه فراخوانی به پایگاه داده یا سایر اجزای خارجی سیستم) این محدودیت نیازمند آن است که اشیا مدل، اشیا قدیمی ساده باشند، اشیایی که منطق تجاری رو بدون تکیه و ترکیب مستقیم چارچوب زیرساختی پیاده سازی میکنند
زبان فراگیر:
تاکید بر منطق تجاری به جای نگرانی های فنی، پیروی از اصطلاحات زبان فراگیر بافت محدود را برای اشیاء مدل دامنه آسان تر می کند. به عبارت دیگر، این الگو به کد اجازه میدهد تا به زبان فراگیر صحبت کند و از مدلهای ذهنی متخصصان حوزه پیروی کند
بلوک‌های ساختمانی:
بیایید به بلوک‌های ساختمانی مدل دامنه مرکزی یا الگوهای تاکتیکی ارائه‌شده توسط DDD نگاهی بیندازیم: اشیاء ارزشvalue object، مجموعه‌ها aggregate و خدمات دامنه domain service
شئ ارزش value object:
شئی است که با ترکیب مقادیر آن قابل شناسایی است (بجای هویت با خصوصیات آن شناسایی میشود)
برای مثال به کلاس فرد دقت کنید
این کلاس میتواند هر مقداری رو بگیرد و هیچگونه مقدار یکتایی رو نمیده، تیکه بر انواع داده‌های ابتدایی کتابخانه استاندارد زبان مانند رشته‌ها و اعداد صحیح برای نمایش مفاهیم حوزه کسب و کار بعنوان بوی کد اولیه obsession شناخته میشود، سیستم به کاربر نمیتواند اعتماد کند که همیشه مقادیر صحیح وارد کند لذا لازم است مقادیر اعتبارسنجی شود، این رویکرد ریسک های طراحی متعددی را ارائه می دهد. اول، منطق اعتبارسنجی تمایل به تکرار دارد. دوم، اجرای فراخوانی منطق اعتبارسنجی قبل از استفاده از مقادیر، دشوار است. در آینده، زمانی که پایه کد توسط مهندسان دیگر تکامل یابد، چالش برانگیزتر خواهد شد. به مقدار اصلاح شده زیر نگاه کنید
ابتدا وضوح در آن افزایش یافته است و در زبان فراگیر در حوزه کسب و کار، مفاهیم با همین اسامی صدا زده میشوند، دوم، نیازی به اعتبارسنجی مقادیر قبل از تخصیص نیست، زیرا منطق اعتبارسنجی در خود اشیاء ارزش قرار دارد. با این حال، رفتار یک شیء ارزشی به اعتبارسنجی صرف محدود نمی شود. اشیاء ارزشی زمانی که منطق تجاری را که ارزش ها را دستکاری می کند متمرکز می کنند، درخشانتر میشود. منطق منسجم در یک مکان پیاده سازی شده است و به راحتی قابل آزمایش است.
اشیاء ارزش نیاز به قراردادها را از بین می‌برند، برای مثال: نیاز به در نظر گرفتن این نکته که این رشته یک ایمیل است و رشته دیگر یک شماره تلفن است، و در عوض با استفاده از مدل شی ایجاد میکند. کمتر مستعد خطا و شهودی تر می‌باشد
زمان استفاده از اشیاء ارزشی
پاسخ ساده این است که هر زمان که بتوانید. نه تنها اشیاء ارزش کد را گویاتر میکنند و منطق تجاری را که تمایل به پراکندگی دارند در بر می‌گیرد، بلکه الگوی کد را ایمن‌تر میکند. از آنجایی که اشیاء ارزشی تغییرناپذیر هستند، رفتار اشیای ارزشی عاری از عوارض جانبی بوده و به صورت نخ است.
موجودیت‌ها:
یک موجودیت مخالف یک شیء ارزشی است. برای تمایز بین نمونه‌های مختلف موجودیت، به یک فیلد شناسایی صریح نیاز دارد
#DDD
#domain_driven_design
@code_crafters
به مباحث منطق تجاری رسیدین قلب تپنده هر سیستمی در پست‌های قبلی دو الگوی ساده اسکریپت و الگوی فعال رو بررسی کردیم و در ادامه مباحث منطق تجاری، الگوی دامنه پیچیده رو بررسی میکنیم، الگوی «مدل دامنه» مجموع‌ها و اشیا ارزش بلوک‌های سازنده آن است
الگوی مدل دامنه برای مقابله با موارد منطق تجاری پیچیده در نظر گرفته شده است.
در اینجا، به‌جای رابطهای CRUD، با انتقال‌های حالت پیچیده، قوانین تجاری، و متغیرها سروکار داریم: قوانینی که همیشه باید محافظت شوند. برای مثال یک سیستم مدیریت پیام بصورت ارزش گذاری روی پیام‌هارو در نظر بگیرید(یک سیستم help desk) که شامل یکسری الزامات هست که مانند یک شبکه درهم تنیده از وابستگی‌ها قوانینی که همگی بر چرخه حیات سیستم تاثیر گذار است، تلاش برای پیاده سازی این منطق با استفاده از اشیا رکورد فعال تکرار منطق را میسر میکند و با اجرای نادرست برخی قوانین تجاری، وضعیت سیستم را خراب میکند
پیاده‌سازی:
مدل دامنه یک مدل شی از دامنه است که هم رفتار و هم داده‌ها را در بر می‌گیرد. الگوهای تاکتیکی DDD - مجموع‌ها، اشیاء ارزش، رویدادهای دامنه و خدمات دامنه - بلوک‌های سازنده چنین مدل شی هستند. همه این الگوها منطق تجاری را در اولویت قرار می دهند
پیچیدگی:
منطق تحاری دامنه ذاتا پیچیده است، بنابراین در مدلسازی آن نباید پیچیدگی اضافی ایجاد کرد. مدل نباید درگیر نگرانی‌های زیرساختی و موارد مربوط به تکنولوژی باشد(مثه فراخوانی به پایگاه داده یا سایر اجزای خارجی سیستم) این محدودیت نیازمند آن است که اشیا مدل، اشیا قدیمی ساده باشند، اشیایی که منطق تجاری رو بدون تکیه و ترکیب مستقیم چارچوب زیرساختی پیاده سازی میکنند
زبان فراگیر:
تاکید بر منطق تجاری به جای نگرانی های فنی، پیروی از اصطلاحات زبان فراگیر بافت محدود را برای اشیاء مدل دامنه آسان تر می کند. به عبارت دیگر، این الگو به کد اجازه میدهد تا به زبان فراگیر صحبت کند و از مدلهای ذهنی متخصصان حوزه پیروی کند
بلوک‌های ساختمانی:
بیایید به بلوک‌های ساختمانی مدل دامنه مرکزی یا الگوهای تاکتیکی ارائه‌شده توسط DDD نگاهی بیندازیم: اشیاء ارزشvalue object، مجموعه‌ها aggregate و خدمات دامنه domain service
شئ ارزش value object:
شئی است که با ترکیب مقادیر آن قابل شناسایی است (بجای هویت با خصوصیات آن شناسایی میشود)
برای مثال به کلاس فرد دقت کنید
class Person:
phone:int
name:str
email:str
این کلاس میتواند هر مقداری رو بگیرد و هیچگونه مقدار یکتایی رو نمیده، تیکه بر انواع داده‌های ابتدایی کتابخانه استاندارد زبان مانند رشته‌ها و اعداد صحیح برای نمایش مفاهیم حوزه کسب و کار بعنوان بوی کد اولیه obsession شناخته میشود، سیستم به کاربر نمیتواند اعتماد کند که همیشه مقادیر صحیح وارد کند لذا لازم است مقادیر اعتبارسنجی شود، این رویکرد ریسک های طراحی متعددی را ارائه می دهد. اول، منطق اعتبارسنجی تمایل به تکرار دارد. دوم، اجرای فراخوانی منطق اعتبارسنجی قبل از استفاده از مقادیر، دشوار است. در آینده، زمانی که پایه کد توسط مهندسان دیگر تکامل یابد، چالش برانگیزتر خواهد شد. به مقدار اصلاح شده زیر نگاه کنید
class Person:
phone:Phone
name:Name
email:Email
ابتدا وضوح در آن افزایش یافته است و در زبان فراگیر در حوزه کسب و کار، مفاهیم با همین اسامی صدا زده میشوند، دوم، نیازی به اعتبارسنجی مقادیر قبل از تخصیص نیست، زیرا منطق اعتبارسنجی در خود اشیاء ارزش قرار دارد. با این حال، رفتار یک شیء ارزشی به اعتبارسنجی صرف محدود نمی شود. اشیاء ارزشی زمانی که منطق تجاری را که ارزش ها را دستکاری می کند متمرکز می کنند، درخشانتر میشود. منطق منسجم در یک مکان پیاده سازی شده است و به راحتی قابل آزمایش است.
اشیاء ارزش نیاز به قراردادها را از بین می‌برند، برای مثال: نیاز به در نظر گرفتن این نکته که این رشته یک ایمیل است و رشته دیگر یک شماره تلفن است، و در عوض با استفاده از مدل شی ایجاد میکند. کمتر مستعد خطا و شهودی تر می‌باشد
زمان استفاده از اشیاء ارزشی
پاسخ ساده این است که هر زمان که بتوانید. نه تنها اشیاء ارزش کد را گویاتر میکنند و منطق تجاری را که تمایل به پراکندگی دارند در بر می‌گیرد، بلکه الگوی کد را ایمن‌تر میکند. از آنجایی که اشیاء ارزشی تغییرناپذیر هستند، رفتار اشیای ارزشی عاری از عوارض جانبی بوده و به صورت نخ است.
موجودیت‌ها:
یک موجودیت مخالف یک شیء ارزشی است. برای تمایز بین نمونه‌های مختلف موجودیت، به یک فیلد شناسایی صریح نیاز دارد
#DDD
#domain_driven_design
@code_crafters
❤6
شی ارزشی بر اساس خصوصیاتش متمایز میشد-دو شئ با خصوصیات یکسان یکی هستند-و تغییر ناپذیر، اما موجودیت یک هویت یکتایی دارد حتی اگر خصوصیات یکسانی داشته باشند و تغییرپذیر هم می‌باشند
برای مثال: کلاس شخص در مثال رو فقط با فیلد نام در نظر بگیرید، این فیلد یکتا نیست چون دو نفر میتوانند یک اسم داشته باشند هرچند هویت واقعی آنها جداست اما برای شناسایی کافی نیست لذا فیلدی مانند id یا کدملی نیز دارد، شرط اصلی فیلد شناسایی یکتا بودن آن است، موجودیت‌ها تغییر پذیرند و انتظار میرود تغییر کنند، موحودیت‌ها یک بلوک ساختمانی ضروری برای هر حوزه تجاری هستند، ما موجودیت‌ها رو در چارچوب الگوی کل اجرا میکنیم و به این دلیل در لیست بلوک‌های سازنده مدل دامنه قرار نمی‌دهیم
در پست‌های قبلی گفته بودم که اکانت کاربری یک موجودیت است اما پروفایل اون هویت است، کاربرد کلمه هویت‌ها در جایگاه استفاده معنای متفاوت است، لازم بذکر است که از دیدگاه DDD اکانت و پروفایل هردو موجودیت هستند که پروفایل بسته به طراحی و کاربرد آن میتواند یک موجودیت جدا باشد، منطق موجودیت اکانت بابت کنترل دسترسی و محدودیت است و منطق پروفایل مدیریت اطلاعات شخصی و نمایش آن است
تجمیع‌ها aggregate:
یک تجمیع در واقع یک موجودیت است، که انتظار میرود تغییر کند، هدف از این الگو محافظت از ثبات داده‌های آن است، از آنجا که داده‌های تجمیع قابل تغییر هستند پیامدها و چالش‌هایی وجود دارد که الگو باید برای ثابت نگه داشتن وضعیت خود در همه زمانها به آنها رسیدگی کند
اجرای سازگاری:
وضعیت یک تجمیع می تواند جهش یابد، که دریچه ای برای راه های متعددی ایجاد می کند که در آن داده های آن می توانند خراب شوند. برای اعمال سازگاری داده ها، الگوی کل یک مرز واضح بین کل و محدوده بیرونی آن ترسیم می کند: کل یک مرز اجرای سازگاری است. منطق تجمیع باید تمام اصلاحات دریافتی را تأیید کند و اطمینان حاصل کند که تغییرات با قوانین تجاری آن مغایرت ندارد. از منظر پیاده سازی، سازگاری با اجازه دادن به منطق تجاری تجمیع برای تغییر وضعیت آن اعمال می شود. تمام فرآیندها یا اشیاء خارج از تجمیع فقط مجاز به خواندن وضعیت تجمع هستند .حالت آن را فقط می توان با اجرای روش های مربوط به رابط عمومی تجمیع تغییر داد. مقابله با منطق تجاری پیچیده روش‌های تغییر حالت که به‌عنوان واسط عمومی یک تجمیع در معرض نمایش قرار می‌گیرند، اغلب به عنوان دستورات شناخته میشوند، مانند «فرمان انجام کاری». یک دستور به دو صورت قابل پیاده سازی است. اول، می توان آن را به عنوان یک روش عمومی ساده از شی انبوه پیاده سازی کرد: افزودن یک متد به موجودیت روت برای مثال یک کلاس سفارشات داریم که یک متد افزودن تعداد سفارشات در خود کلاس جاساز شده است. از طرف دیگر، یک فرمان را می توان به عنوان یک شی پارامتر نشان داد (اشیاء فرمان) که تمام ورودی های مورد نیاز برای اجرای دستور را محصور می کند: برای مثال متدی که شی را گرفته و متد افزودن را اجرا میکند
اطمینان از اینکه دیتابیس مدنظر از روش همزمانی پشتیبانی میکند الزامی است
مرز تراکنشی:
از آنجایی که وضعیت یک تجمیع فقط با منطق تجاری خودش قابل تغییر است، تجمیع به عنوان یک مرز معاملاتی نیز عمل می کند. تمام تغییرات در وضعیت کل باید به صورت یک عملیات اتمی انجام شود. اگر وضعیت یک تجمیع اصلاح شود، یا تمام تغییرات انجام می شود یا هیچ یک از آنها انجام نمی شود. علاوه بر این، هیچ عملیات سیستمی نمی تواند یک تراکنش چند انبوه را فرض کند. تغییر در وضعیت یک تجمیع فقط می تواند به صورت جداگانه انجام شود، یک تجمیع در هر تراکنش پایگاه داده. یک نمونه انبوه در هر تراکنش ما را مجبور میکند تا مرزهای تجمیع را با دقت طراحی کنیم، و اطمینان حاصل کنیم که طرح به تغییرات و قوانین حوزه کسب‌وکار می‌پردازد. نیاز به انجام تغییرات در تجمیع‌های متعدد، یک مرز تراکنش اشتباه و از این رو، مرزهای کل اشتباه را نشان می دهد. به نظر می رسد که این یک محدودیت مدل سازی را تحمیل می کند. اگر بخواهیم چندین شی را در یک تراکنش تغییر دهیم چه؟ بیایید ببینیم الگو چگونه چنین موقعیت‌هایی را نشان میدهد.
ما از موجودیت ها به عنوان یک الگوی مستقل استفاده نمی کنیم، بلکه تنها به عنوان بخشی از یک تجمیع در نظر میگیریم. بیایید تفاوت اساسی بین موجودیت ها و تجمیع‌ها را ببینیم، و اینکه چرا موجودیت ها به جای مدل دامنه فراگیر، بلوک ساختمانی یک تجمیع هستند
#DDD
#domain_driven_diven
@code_crafters
❤6
سناریوهای تجاری وجود دارد که در آنها چندین شی باید، یک مرز معاملاتی را به اشتراک بگذارند. به عنوان مثال، زمانی که هر دو را میتوان به طور همزمان تغییر داد یا قوانین تجاری یک شی به وضعیت یک شی دیگر بستگی دارد. DDD تجویز می کند که طراحی یک سیستم باید توسط دامنه تجاری آن هدایت شود. تجمیع نیز از این قاعده مستثنی نیستند. برای پشتیبانی از تغییرات در اشیاء متعددی که باید در یک تراکنش اتمی اعمال شوند، الگوی تجمیع شبیه سلسله مراتبی از موجودیت‌ها است. سلسله مراتب شامل هر دو موجودیت و اشیاء ارزشی است و همه آنها در صورتی که به منطق تجاری دامنه محدود شوند به یک تجمیع تعلق دارند. به همین دلیل است که این الگو «تجمیع» نامیده میشود: این الگو نهادهای تجاری و اشیاء ارزشی را که به یک مرز معامله تعلق دارند، جمع‌آوری میکند. نمونه کد زیر یک قانون کسب‌وکار را نشان میدهد که چندین نهاد متعلق به مرز کل را در بر می‌گیرد. تجمیع تضمین میکند که همه شرایط در برابر داده‌های کاملاً سازگار بررسی میشوند، و پس از تکمیل بررسی‌ها با اطمینان از اینکه همه تغییرات در داده‌های کل به‌عنوان یک تراکنش اتمی انجام میشوند، تغییری نمی‌کند.
ارجاع به سایر تجمیع‌ها:
از آنجایی که تمام اشیاء موجود در یک تجمیع دارای مرز تراکنشی یکسانی هستند، در صورت بزرگ شدن بیش از حد یک تجمیع، ممکن است مسائل مربوط به عملکرد و مقیاس پذیری ایجاد شود. سازگاری داده ها می تواند یک اصل راهنمای مناسب برای طراحی مرزهای یک تجمیع باشد. فقط اطلاعاتی که توسط منطق تجاری کل مورد نیاز است تا به شدت سازگار باشد باید بخشی از کل باشد. تمام اطلاعاتی که در نهایت میتوانند سازگار باشند، باید خارج از مرز تجمیع باشند. قاعده کلی این است که تجمیع‌ها تا حد امکان کوچک نگه داشته شوند و فقط اشیایی را در بر گیرد که طبق منطق تجاری تجمیع باید در یک حالت کاملاً سازگار باشند
ریشه تجمیع aggregate root:
وضعیت یک تجمیع فقط با اجرای یکی از دستورات آن قابل تغییر است. از آنجایی که یک تجمیع نشان دهنده سلسله مراتبی از موجودیت ها است (هر تجمیع میتواند شامل چند موجودیت باشد)، تنها یکی از آنها باید به عنوان رابط عمومی تجمیع تعیین شود. برای مثال در بافت محدود به سیستم تیکتینگ و موجودیت‌های آن که شامل ticket, messages, attachments ، میشود ticket بعنوان root شناخته میشود
رویدادهای دامنه domain events:
رویداد دامنه پیامی است که رویداد مهمی را که در حوزه کسب و کار رخ داده است توصیف می کند. برای مثال: بلیط اختصاص داده شده، بلیط افزایش یافته،پیام دریافت شده.
از آنجایی که رویدادهای دامنه چیزی را توصیف می کنند که قبلاً اتفاق افتاده است، نام آنها باید در زمان گذشته فرموله شود. هدف یک رویداد دامنه توصیف آنچه در حوزه کسب و کار اتفاق افتاده و ارائه تمام داده های لازم مربوط به رویداد است. به عنوان مثال، رویداد دامنه زیر نشان می دهد که بلیط خاص، در چه زمانی و به چه دلیل افزایش یافته است
مانند همه چیز در مهندسی نرم افزار، نامگذاری نیز مهم است. اطمینان حاصل کنید که نام رویدادهای دامنه به طور خلاصه منعکس کننده آنچه در حوزه کسب و کار اتفاق افتاده است. رویدادهای دامنه بخشی از رابط عمومی یک مجموعه هستند. یک مجموعه رویدادهای دامنه خود را منتشر می کند. سایر فرآیندها، تجمیع‌ها یا حتی سیستم‌های خارجی میتوانند در پاسخ به رویدادهای دامنه، مشترک شوند و منطق خود را اجرا کنند
زبان فراگیر:
آخرین اما نه کم‌اهمیت‌ترین، تجمیع‌ها باید انعکاسی از زبان فراگیر باشند. اصطلاحاتی که برای نام تجمیع، اعضای داده‌های آن، اقدامات و رویدادهای دامنه آن استفاده میشود، همگی باید به زبان فراگیر بافت محدود فرموله شوند. کد باید بر اساس همان زبانی باشد که توسعه دهندگان هنگام صحبت با یکدیگر و با کارشناسان حوزه از آن استفاده می کنند. این امر به ویژه برای اجرای منطق پیچیده تجاری مهم است
خدمات دامنه domain service:
دیر یا زود، ممکن است با منطق تجاری مواجه شوید که یا به هیچ شیء تجمیع یا ارزشی تعلق ندارد، یا به نظر می رسد که به چندین مجموعه مرتبط باشد. در چنین مواردی، طراحی دامنه محور پیشنهاد می کند که منطق را به عنوان یک سرویس دامنه پیاده سازی کند. یک سرویس دامنه یک شیء بدون حالت است که منطق تجاری را پیاده سازی می کند. در اکثریت قریب به اتفاق موارد، چنین منطقی فراخوانی به اجزای مختلف سیستم را برای انجام برخی محاسبات یا تجزیه و تحلیل هماهنگ می کند.
#DDD
#domain_driven_design
@code_crafters
ارجاع به سایر تجمیع‌ها:
از آنجایی که تمام اشیاء موجود در یک تجمیع دارای مرز تراکنشی یکسانی هستند، در صورت بزرگ شدن بیش از حد یک تجمیع، ممکن است مسائل مربوط به عملکرد و مقیاس پذیری ایجاد شود. سازگاری داده ها می تواند یک اصل راهنمای مناسب برای طراحی مرزهای یک تجمیع باشد. فقط اطلاعاتی که توسط منطق تجاری کل مورد نیاز است تا به شدت سازگار باشد باید بخشی از کل باشد. تمام اطلاعاتی که در نهایت میتوانند سازگار باشند، باید خارج از مرز تجمیع باشند. قاعده کلی این است که تجمیع‌ها تا حد امکان کوچک نگه داشته شوند و فقط اشیایی را در بر گیرد که طبق منطق تجاری تجمیع باید در یک حالت کاملاً سازگار باشند
ریشه تجمیع aggregate root:
با اسامی موجودیت ریشه root entity نیز شناخته میشود
وضعیت یک تجمیع فقط با اجرای یکی از دستورات آن قابل تغییر است. از آنجایی که یک تجمیع نشان دهنده سلسله مراتبی از موجودیت ها است (هر تجمیع میتواند شامل چند موجودیت باشد)، تنها یکی از آنها باید به عنوان رابط عمومی تجمیع تعیین شود. برای مثال در بافت محدود به سیستم تیکتینگ و موجودیت‌های آن که شامل ticket, messages, attachments ، میشود ticket بعنوان root شناخته میشود
علاوه بر رابط عمومی ریشه تجمیع، مکانیسم دیگری وجود دارد که از طریق آن دنیای بیرونی می تواند با تجمیع‌ها ارتباط برقرار کند: رویدادهای دامنه domain events
رویدادهای دامنه domain events:
رویداد دامنه پیامی است که رویداد مهمی را که در حوزه کسب و کار رخ داده است توصیف می کند. برای مثال: بلیط اختصاص داده شده، بلیط افزایش یافته،پیام دریافت شده.
از آنجایی که رویدادهای دامنه چیزی را توصیف می کنند که قبلاً اتفاق افتاده است، نام آنها باید در زمان گذشته فرموله شود. هدف یک رویداد دامنه توصیف آنچه در حوزه کسب و کار اتفاق افتاده و ارائه تمام داده های لازم مربوط به رویداد است. به عنوان مثال، رویداد دامنه زیر نشان می دهد که بلیط خاص، در چه زمانی و به چه دلیل افزایش یافته است
مانند همه چیز در مهندسی نرم افزار، نامگذاری نیز مهم است. اطمینان حاصل کنید که نام رویدادهای دامنه به طور خلاصه منعکس کننده آنچه در حوزه کسب و کار اتفاق افتاده است. رویدادهای دامنه بخشی از رابط عمومی یک مجموعه هستند. یک مجموعه رویدادهای دامنه خود را منتشر می کند. سایر فرآیندها، تجمیع‌ها یا حتی سیستم‌های خارجی میتوانند در پاسخ به رویدادهای دامنه، مشترک شوند و منطق خود را اجرا کنند
زبان فراگیر:
آخرین اما نه کم‌اهمیت‌ترین، تجمیع‌ها باید انعکاسی از زبان فراگیر باشند. اصطلاحاتی که برای نام تجمیع، اعضای داده‌های آن، اقدامات و رویدادهای دامنه آن استفاده میشود، همگی باید به زبان فراگیر بافت محدود فرموله شوند. کد باید بر اساس همان زبانی باشد که توسعه دهندگان هنگام صحبت با یکدیگر و با کارشناسان حوزه از آن استفاده می کنند. این امر به ویژه برای اجرای منطق پیچیده تجاری مهم است
خدمات دامنه domain service:
دیر یا زود، ممکن است با منطق تجاری مواجه شوید که یا به هیچ شیء تجمیع یا ارزشی تعلق ندارد، یا به نظر می رسد که به چندین مجموعه مرتبط باشد. در چنین مواردی، طراحی دامنه محور پیشنهاد می کند که منطق را به عنوان یک سرویس دامنه پیاده سازی کند. یک سرویس دامنه یک شیء بدون حالت است که منطق تجاری را پیاده سازی می کند. در اکثریت قریب به اتفاق موارد، چنین منطقی فراخوانی به اجزای مختلف سیستم را برای انجام برخی محاسبات یا تجزیه و تحلیل هماهنگ می کند.
#DDD
#domain_driven_design
@code_crafters
❤5
خدمات دامنه، هماهنگی بین چندین مجموعه را آسان می کند.اما مهم است که همیشه محدودیت الگوی تحمیع را برای اصلاح تنها یک نمونه از یک مجموعه در یک تراکنش پایگاه داده در نظر داشته باشید(خدمات دامنه یک راه گریز برای آن نیست) قانون یک نمونه در هر تراکنش همچنان وجود دارد. در عوض، سرویس‌های دامنه خود را به پیاده‌سازی منطق محاسباتی که نیازمند خواندن داده‌های چند مجموعه است، می‌دهند. سرویس دامنه فقط یک شیء بدون حالت است که برای میزبانی منطق تجاری استفاده می شود.
مدیریت پیچیدگی:
همانطور که در مقدمه این فصل اشاره شد، الگوهای شی تجمیع و ارزش به عنوان ابزاری برای مقابله با پیچیدگی در اجرای منطق تجاری معرفی شدند. بیایید دلیل پشت این موضوع را ببینیم
الگوهای شی تجمیع و ارزش، ثابت ها را محصور می کنند و در نتیجه پیچیدگی را کاهش می دهند.
تمام منطق تجاری مربوط به وضعیت یک شی ارزش در مرزهای آن قرار دارد.
همین امر در مورد سنگدانه ها نیز صادق است. یک مجموعه را فقط می توان با روش های خاص خود اصلاح کرد. منطق تجاری آن، متغیرهای کسب و کار را محصور می کند و از آن محافظت می کند، بنابراین درجات آزادی را کاهش می دهد.
از آنجایی که الگوی مدل دامنه فقط برای زیر دامنه‌هایی با منطق تجاری پیچیده اعمال میشود، میتوان فرض کرد که اینها زیردامنه‌های اصلی - قلب نرم‌افزار هستند.
#DDD
#domain_driven_design
@code_crafters
مدیریت پیچیدگی:
همانطور که در مقدمه این فصل اشاره شد، الگوهای شی تجمیع و ارزش به عنوان ابزاری برای مقابله با پیچیدگی در اجرای منطق تجاری معرفی شدند. بیایید دلیل پشت این موضوع را ببینیم
به گفته گلدرات، هنگام بحث در مورد پیچیدگی یک سیستم، ما علاقه مندیم که دشواری کنترل و پیش بینی رفتار سیستم را ارزیابی کنیم. این دو جنبه توسط درجات آزادی سیستم منعکس می شود. درجات آزادی یک سیستم، نقاط داده مورد نیاز برای توصیف وضعیت آن است
الگوهای شی تجمیع و ارزش، ثابت ها را محصور می کنند و در نتیجه پیچیدگی را کاهش می دهند.
تمام منطق تجاری مربوط به وضعیت یک شی ارزش در مرزهای آن قرار دارد.
همین امر در مورد سنگدانه ها نیز صادق است. یک مجموعه را فقط می توان با روش های خاص خود اصلاح کرد. منطق تجاری آن، متغیرهای کسب و کار را محصور می کند و از آن محافظت می کند، بنابراین درجات آزادی را کاهش می دهد.
از آنجایی که الگوی مدل دامنه فقط برای زیر دامنه‌هایی با منطق تجاری پیچیده اعمال میشود، میتوان فرض کرد که اینها زیردامنه‌های اصلی - قلب نرم‌افزار هستند.
#DDD
#domain_driven_design
@code_crafters
❤8
در پست قبلی درباره الگوی مدل دامنه حرف زدیم(بلوک‌های سازنده، هدف و زمینه کاربردی آن) الگوی مدل دامنه منبع رویداد بر اساس همان فرض الگوی مدل دامنه است، منطق تجاری پیچیده و متعلق به زیردامنه اصلی است و از الگوهای تاکتیکی مانند اشیا ارزش، تجمیع‌ها و رویدادهای دامنه استفاده میکند. تفاوت بین آنها به تداوم وضعیت، تجمیع نهفته وابسته است، مدل دامنه منبع رویداد از الگوی منبع‌یابی رویداد برای مدیریت حالت‌های تجمیع استفاده میکند(مدل بجای تداوم وضعیت یک تجمیع، رویدادهای دامنه رو تولید میکنه، که هر تغییر رو توصیف و از آنها بعنوان منبع حقیقت برای داده‌های تجمیع استفاده میکند)
در این بخش با معرفی مفهوم منبع رویداد، ترکیب آن با الگوی مدل دامنه و تبدیل آن به یک مدل دامنه منبع رویداد، صحبت میکنیم
منبع یابی رویداد:
بیایید از استدلال بالا برای تعریف الگوی منبع یابی رویداد استفاده کنیم و تفاوت آن با مدل سازی سنتی و تداوم داده ها را درک کنیم. تصویر اول در کامنت‌ها را بررسی کنید و آنچه را که می توانید از این داده ها در مورد سیستمی که به آن تعلق دارد بیاموزید، تجزیه و تحلیل کنید.
این یک جدول بازاریابی است که شامل افراد و وضعیت انها می‌باشد که status فیلد وضعیت هر کاربر را مشخص میکند(نفر جدید، خرید شده، عدم خرید و بسته)
این اطلاعات بسیار زیادی است که می‌توانیم فقط با تجزیه و تحلیل طرحواره جدول و داده‌های ذخیره شده در آن جمع‌آوری کنیم. حتی می‌توانیم فرض کنیم که هنگام مدلسازی داده‌ها از چه زبانی استفاده شده است. اما از فرآیند کاری که روی هر مشتری صورت گرفته اطلاعی نداریم و این موجب نگرانی‌های کسب و کار میشود و نمیتوان تصمیمات درستی در مورد هر مشتری گرفت، حال اگر یه فیلد version روی مدل بزاریم و بابت هر مرحله مشخص انجام شده یک مقدار عددی به آن نسبت بدهیم با یک نگاه گذرا میتوان به یک سفر در گذشته رفت، برای مثال: مقدار ۱ اطلاعات از مشتری گرفته شده، مقدار ۲ کارشناسان با مشتری تماس گرفته‌اند، مقدار ۳ تاییدیه از مشتری گرفته شده است و ... علاوه بر ان میتوان پی برد چه تعداد مشتری در چه بخش یا واحد سازمان هستند و تحلیل‌های بسیار دیگری
تجزیه و تحلیل:
بخش هوش تجاری از شما میخواهد در مدل خود برنامه تماس‌های آینده با مشتریان رو فراهم کنید و به این ترتیب با فیلتر این بخش و بخش قبلی به پیش بینی بپردازند، شما باید این پیش بینی رو جایی نگهداری کنید تا بعدا در دسترس باشد، این فرآیند در الگوی CQRS صورت میگرد که در آینده راجب آن حرف خواهیم زد
منبع حقیقت:
برای اینکه الگوی منبع یابی رویداد کار کند، همه تغییرات در وضعیت یک شی باید به عنوان رویداد نشان داده شود و ادامه یابد. این رویدادها منبع حقیقت سیستم می شوند. مجموعه منبع رویداد پایگاه داده ای که رویدادهای سیستم را ذخیره می کند، تنها ذخیره سازی کاملاً سازگار است: منبع حقیقت سیستم است، نام پذیرفته شده برای پایگاه داده ای که برای رویدادهای ماندگار استفاده می شود، ذخیره رویداد است.
ذخیره رویداد:
ذخیره رویداد نباید اجازه تغییر یا حذف رویدادها را بدهد، برای پشتیبانی از اجرای الگوی منبع یابی رویداد، حداقل ذخیره رویداد باید از عملکرد زیر پشتیبانی کند: واکشی همه رویدادهای متعلق به یک نهاد تجاری خاص و پیوست رویدادها.
منبع رویداد مدل دامنه:
مدل اصلی دامنه یک نمایش از حالت تجمیع خود را حفظ میکند و رویدادهای دامنه انتخابی را منتشر میکند. مدل دامنه منبع رویداد، بطور انحصاری از رویدادهای دامنه برای مدلسازی چرخه عمر تجمیع‌ها استفاده میکند(تمام تغییرات در وضعیت یک تجمیع باید بعنوان رویدادهای دامنه بیان شوند)
بیایید برخی از مزایای استفاده از منابع رویداد هنگام اجرای منطق پیچیده تجاری نگاهی بیندازیم.
مزایا:
در مقایسه با مدل سنتی تر، که در آن حالت های فعلی مجموع ها در یک پایگاه داده حفظ می شود، مدل دامنه منبع رویداد به تلاش بیشتری برای مدل سازی کل نیاز دارد. با این حال، این رویکرد دارای مزایای قابل توجهی است که باعث می شود الگو در بسیاری از سناریوها مورد توجه قرار گیرد:
#DDD
#domain_driven_design
@code_crafters
در این بخش با معرفی مفهوم منبع رویداد، ترکیب آن با الگوی مدل دامنه و تبدیل آن به یک مدل دامنه منبع رویداد، صحبت میکنیم
منبع یابی رویداد:
نمودار جریان خود را به من نشان دهید و جداول خود را پنهان کنید، و من همچنان مرموز خواهم بود. جداول خود را به من نشان دهید، و من معمولاً به فلوچارت شما نیاز نخواهم داشت. آشکار خواهد شد
بیایید از استدلال بالا برای تعریف الگوی منبع یابی رویداد استفاده کنیم و تفاوت آن با مدل سازی سنتی و تداوم داده ها را درک کنیم. تصویر اول در کامنت‌ها را بررسی کنید و آنچه را که می توانید از این داده ها در مورد سیستمی که به آن تعلق دارد بیاموزید، تجزیه و تحلیل کنید.
این یک جدول بازاریابی است که شامل افراد و وضعیت انها می‌باشد که status فیلد وضعیت هر کاربر را مشخص میکند(نفر جدید، خرید شده، عدم خرید و بسته)
این اطلاعات بسیار زیادی است که می‌توانیم فقط با تجزیه و تحلیل طرحواره جدول و داده‌های ذخیره شده در آن جمع‌آوری کنیم. حتی می‌توانیم فرض کنیم که هنگام مدلسازی داده‌ها از چه زبانی استفاده شده است. اما از فرآیند کاری که روی هر مشتری صورت گرفته اطلاعی نداریم و این موجب نگرانی‌های کسب و کار میشود و نمیتوان تصمیمات درستی در مورد هر مشتری گرفت، حال اگر یه فیلد version روی مدل بزاریم و بابت هر مرحله مشخص انجام شده یک مقدار عددی به آن نسبت بدهیم با یک نگاه گذرا میتوان به یک سفر در گذشته رفت، برای مثال: مقدار ۱ اطلاعات از مشتری گرفته شده، مقدار ۲ کارشناسان با مشتری تماس گرفته‌اند، مقدار ۳ تاییدیه از مشتری گرفته شده است و ... علاوه بر ان میتوان پی برد چه تعداد مشتری در چه بخش یا واحد سازمان هستند و تحلیل‌های بسیار دیگری
برای مثال این نوع رویکرد در سفارشات یک فروشگاه از درخواست تا مرحله تحویل را زیر نظر گرفت برای مثال: -ساخت سبد(0)»افزودن کالا(1)»ثبت سبد(2)»پرداخت(3)»در حال بررسی(4)»تخصیص منابع(5)»ارسال(6)»تحویل(7)-
تجزیه و تحلیل:
بخش هوش تجاری از شما میخواهد در مدل خود برنامه تماس‌های آینده با مشتریان رو فراهم کنید و به این ترتیب با فیلتر این بخش و بخش قبلی به پیش بینی بپردازند، شما باید این پیش بینی رو جایی نگهداری کنید تا بعدا در دسترس باشد، این فرآیند در الگوی CQRS صورت میگرد که در آینده راجب آن حرف خواهیم زد
منبع حقیقت:
برای اینکه الگوی منبع یابی رویداد کار کند، همه تغییرات در وضعیت یک شی باید به عنوان رویداد نشان داده شود و ادامه یابد. این رویدادها منبع حقیقت سیستم می شوند. مجموعه منبع رویداد پایگاه داده ای که رویدادهای سیستم را ذخیره می کند، تنها ذخیره سازی کاملاً سازگار است: منبع حقیقت سیستم است، نام پذیرفته شده برای پایگاه داده ای که برای رویدادهای ماندگار استفاده می شود، ذخیره رویداد است.
ذخیره رویداد:
ذخیره رویداد نباید اجازه تغییر یا حذف رویدادها را بدهد، برای پشتیبانی از اجرای الگوی منبع یابی رویداد، حداقل ذخیره رویداد باید از عملکرد زیر پشتیبانی کند: واکشی همه رویدادهای متعلق به یک نهاد تجاری خاص و پیوست رویدادها.
منبع رویداد مدل دامنه:
مدل اصلی دامنه یک نمایش از حالت تجمیع خود را حفظ میکند و رویدادهای دامنه انتخابی را منتشر میکند. مدل دامنه منبع رویداد، بطور انحصاری از رویدادهای دامنه برای مدلسازی چرخه عمر تجمیع‌ها استفاده میکند(تمام تغییرات در وضعیت یک تجمیع باید بعنوان رویدادهای دامنه بیان شوند)
بیایید برخی از مزایای استفاده از منابع رویداد هنگام اجرای منطق پیچیده تجاری نگاهی بیندازیم.
مزایا:
در مقایسه با مدل سنتی تر، که در آن حالت های فعلی مجموع ها در یک پایگاه داده حفظ می شود، مدل دامنه منبع رویداد به تلاش بیشتری برای مدل سازی کل نیاز دارد. با این حال، این رویکرد دارای مزایای قابل توجهی است که باعث می شود الگو در بسیاری از سناریوها مورد توجه قرار گیرد:
#DDD
#domain_driven_design
@code_crafters
❤4👍1
ویژگی‌ها:
معایب:
تا کنون ممکن است به نظر برسد که مدل دامنه منبع رویداد، الگوی نهایی برای پیاده سازی منطق تجاری است و بنابراین باید تا حد امکان استفاده شود. البته، این با اصل اجازه دادن به نیازهای حوزه تجاری در تصمیم گیری های طراحی در تضاد است. بنابراین، اجازه دهید برخی از چالش های ارائه شده توسط الگو را مورد بحث قرار دهیم:
همه این چالش‌ها حتی حادتر میشوند اگر کار در دست استفاده از الگو را توجیه نکند و در عوض بتوان با طراحی ساده‌تر به آن پرداخت. قوانین ساده ای را یاد خواهید گرفت که می تواند به شما کمک کند تصمیم بگیرید که از کدام الگوی پیاده سازی منطق تجاری استفاده کنید.
#DDD
#domain_driven_design
@code_crafters
سفر در زمان:
همانطور که از رویدادهای دامنه می توان برای بازسازی وضعیت فعلی یک مجموعه استفاده کرد، همچنین می توان از آنها برای بازیابی همه حالت های گذشته مجموع استفاده کرد. به عبارت دیگر، شما همیشه می توانید تمام حالات گذشته یک مجموعه را بازسازی کنید.
این اغلب هنگام تجزیه و تحلیل رفتار سیستم، بازرسی تصمیمات سیستم و بهینه سازی منطق تجاری انجام می شود.
یکی دیگر از موارد استفاده رایج برای بازسازی حالت های گذشته، اشکال زدایی ماسبق است:
شما می توانید مجموع را به حالت دقیقی که در هنگام مشاهده یک باگ بود برگردانید.
بینش عمیق:
در پست های اول، دیدیم که بهینه‌سازی زیردامنه‌های اصلی از نظر استراتژیک برای تجارت مهم است. منبع یابی رویداد بینشی عمیق از وضعیت و رفتار سیستم ارائه می دهد. همانطور که قبلاً در این فصل یاد گرفتید، منبع یابی رویداد مدل انعطاف پذیری را ارائه می دهد که امکان تبدیل رویدادها به بازنمایی حالت های مختلف را فراهم می کند - همیشه می توانید پیش بینی های جدیدی را اضافه کنید که از داده های رویدادهای موجود برای ارائه بینش اضافی استفاده می کند.
گزارش حسابرسی:
رویدادهای دامنه تداوم یافته یک گزارش حسابرسی کاملاً سازگار از هر اتفاقی که برای حالت‌های کل اتفاق افتاده است را نشان میدهد. قوانین برخی از حوزه‌های تجاری را ملزم به پیاده‌سازی گزارش‌های حسابرسی میکند، و منبع‌یابی رویداد این امر را خارج از جعبه فراهم میکند.
این مدل به ویژه برای سیستم هایی که پول یا تراکنش های پولی را مدیریت می کنند مناسب است. این به ما اجازه می دهد تا به راحتی تصمیمات سیستم و جریان وجوه بین حساب ها را ردیابی کنیم.
مدیریت همزمان خوش‌بینانه پیشرفته:
مدل کلاسیک همزمانی خوش‌بینانه زمانی که داده‌های خوانده شده کهنه میشوند - توسط یک فرآیند دیگر بازنویسی میشوند - یک استثنا ایجاد میکند. هنگام استفاده از منبع‌یابی رویداد، می‌توانیم بینش عمیق‌تری درباره آنچه که بین خواندن رویدادهای موجود و نوشتن رویدادهای جدید اتفاق افتاده است به دست آوریم. می‌توانید رویدادهای دقیقی را که همزمان به فروشگاه رویداد ضمیمه شده‌اند پرس و جو کنید و در مورد اینکه آیا رویدادهای جدید با عملیات تلاش‌شده تداخل دارند یا رویدادهای اضافی نامربوط هستند، تصمیم‌گیری مبتنی بر دامنه کسب‌وکار بگیرید یا خیر.
معایب:
تا کنون ممکن است به نظر برسد که مدل دامنه منبع رویداد، الگوی نهایی برای پیاده سازی منطق تجاری است و بنابراین باید تا حد امکان استفاده شود. البته، این با اصل اجازه دادن به نیازهای حوزه تجاری در تصمیم گیری های طراحی در تضاد است. بنابراین، اجازه دهید برخی از چالش های ارائه شده توسط الگو را مورد بحث قرار دهیم:
منحنی یادگیری:
نقطه ضعف آشکار الگو تفاوت شدید آن با تکنیک های سنتی مدیریت داده است. اجرای موفقیت آمیز الگو مستلزم آموزش تیم و زمان برای عادت کردن به روش جدید تفکر است. مگر اینکه تیم قبلاً تجربه اجرای سیستم های منبع رویداد را داشته باشد، منحنی یادگیری باید در نظر گرفته شود.
تکامل مدل:
تکامل یک مدل منبع رویداد می تواند چالش برانگیز باشد. تعریف دقیق منبع رویداد می گوید که رویدادها تغییر ناپذیر هستند. اما اگر بخواهید طرح رویداد را تنظیم کنید چه؟ این فرآیند به سادگی تغییر طرح جدول نیست. در واقع، یک کتاب کامل تنها در مورد این موضوع نوشته شده است: نسخه سازی در یک سیستم منبع رویداد توسط گرگ یانگ.
پیچیدگی معماری:
پیاده‌سازی منابع رویداد، «قطعات متحرک» معماری متعددی را معرفی میکند و طراحی کلی را پیچیده‌تر میکند.
همه این چالش‌ها حتی حادتر میشوند اگر کار در دست استفاده از الگو را توجیه نکند و در عوض بتوان با طراحی ساده‌تر به آن پرداخت. قوانین ساده ای را یاد خواهید گرفت که می تواند به شما کمک کند تصمیم بگیرید که از کدام الگوی پیاده سازی منطق تجاری استفاده کنید.
#DDD
#domain_driven_design
@code_crafters
❤4👍1
الگوهای تاکتیکی که تا اینجا مورد بحث قرار گرفت،(راه‌های مختلف مدلسازی و پیاده‌سازی منطق تجاری بود) در این فصل، در یک زمینه گسترده راه های مختلف برای هماهنگ کردن تعاملات و وابستگی ها بین اجزای یک سیستم را بررسی خواهیم کرد
منطق تجاری در مقابل الگوهای طراحی:
منطق تجاری بخش مهمی از یک سیستم است اما همه آن نیست، برای اجرای الزامات کاربردی و غیر کاربردی پایگاه کد مسئولیتهای بیشتری را برعهده بگیرد. برای جمع‌آوری ورودی و ارائه خروجی باید با کاربران تعامل داشته باشد و باید از مکانیسم‌های ذخیره‌سازی مختلف برای تداوم وضعیت و ادغام با سیستم‌های خارجی و ارائه‌دهندگان اطلاعات استفاده کند. نگرانی‌های متنوع یک پایگاه کد منجر میشود که منطق تجاری در بین اجزای یک سیستم منتشر شود(در پایگاه داده، رابط کاربری یا حتی کپی کردن آن در بخش‌های مختلف) عدم سازماندهی کردن نگرانی‌های پیاده سازی، کار را در پایگاه کد سختتر میکند برای مثال هنگام تغییر منطق تجاری ممکن است مشخص نباشد دقیق کجا باید تغییر کند یا هنگام تغییر ممکن است جاهای مختلفی از کار بیافتد یا منجر به از دست رفتن کدهایی شود که نیاز به اصلاح داشتند. الگوهای معماری اصول سازمانی را برای جنبه‌های مختلف یک پایگاه کد معرفی میکنند و مرزهای واضحی را بین آنها ارائه میکنند: اینکه منطق تجاری چگونه به ورودی، خروجی و سایر اجزای زیرساختی سیستم متصل میشود که بر نحوه تعامل آنها اینکه چه دانشی را به اشتراک می‌گذارند و چگونه مولفه‌ها به یکدیگر ارجاع میکنند تاثیر می‌گذارد. انتخاب روش مناسب جهت سازماندهی پایگاه کد، یا الگوریتم معماری صحیح، برای حمایت از اجرای منطق تجاری در کوتاه مدت و کاهش تعمیر و نگهداری در بلند مدت بسیار مهم است. سه الگوی معماری کاربردی غالب شامل: معماری لایه‌ای، پورت‌ها و آداپتورها، CQRS رو باهم بررسی کنیم
معماری لایه‌ای:
یکی از رایجترین الگوهای معماری می‌باشد که پایکاه کد را در لایه‌های افقی سازماندهی میکند و هر لایه به یکی از نگرانی‌های فنی زیر می‌پردازد که شامل: تعامل با مصرف کنندگان(presentation layer)، منطق تجاری(business logic)، تداوم داده‌ها(data access layer) تصویر اول در کامنت‌ها
لایه تعامل که شامل رابطهای ارتباطی است که میتواند gui,cli,restapi,webui باشد-لایه منطق تجاری که بصورت کپسوله شده است(قلب نرم افزار) الگوها و تصمیمات تجاری در آن است- لایه داده که شامل پایگاه داده است که شکل‌های مختلفی از قبیل پایگاه‌های sql,nosql در شکل های مختلفی از حافظه یا حتی اسناد و داکیومنت مانند باشد. ارتباط این لایه ها باهمدیگه از طریق یک کانال مستقیم از بالا به پایین و ترتیبی است بگونه‌ای که لایه تعامل هیچ درک و خبری از لایه تداوم داده ندارد
در معماری لایه‌ای مشاهده یک لایه اضافه معمول است
لایه سرویس:
لایه سرویس مرز یک برنامه را با لایه ای از خدمات تعریف می کند که مجموعه ای از عملیات موجود را ایجاد می کند و پاسخ برنامه را در هر عملیات هماهنگ می کند.( لایه سرویس به عنوان یک واسطه بین لایه های ارائه برنامه و منطق تجاری عمل می کند)
لایه سرویس در واقع یک مرز منطقی است نه یک سرویس فیزیکی، بعنوان یک نما برای منطق تجاری شناخته میشود که مرز لایه تعامل با منطق تجاری رو جدا میکنه،
داشتن یک لایه سرویس واضح چندین مزیت دارد:
یک لایه سرویس همیشه ضروری نیست. به عنوان مثال، زمانی که منطق کسب و کار به عنوان یک اسکریپت تراکنش پیاده‌سازی میشود، اساساً یک لایه سرویس است، زیرا قبلاً مجموعه‌ای از روش‌ها را که رابط عمومی سیستم را تشکیل می‌دهند، نشان میدهد
از سوی دیگر، اگر الگوی منطق تجاری نیاز به هماهنگی خارجی داشته باشد، لایه سرویس مورد نیاز است، همانطور که در مورد الگوی رکورد فعال وجود دارد. در این مورد، لایه سرویس الگوی اسکریپت تراکنش را پیاده‌سازی میکند، در حالی که رکوردهای فعالی که روی آنها کار میکند در لایه منطق تجاری قرار دارند.
اصطلاحات بکار برده شده
#DDD
#domain_driven_desigb
@code_crafters
منطق تجاری در مقابل الگوهای طراحی:
منطق تجاری بخش مهمی از یک سیستم است اما همه آن نیست، برای اجرای الزامات کاربردی و غیر کاربردی پایگاه کد مسئولیتهای بیشتری را برعهده بگیرد. برای جمع‌آوری ورودی و ارائه خروجی باید با کاربران تعامل داشته باشد و باید از مکانیسم‌های ذخیره‌سازی مختلف برای تداوم وضعیت و ادغام با سیستم‌های خارجی و ارائه‌دهندگان اطلاعات استفاده کند. نگرانی‌های متنوع یک پایگاه کد منجر میشود که منطق تجاری در بین اجزای یک سیستم منتشر شود(در پایگاه داده، رابط کاربری یا حتی کپی کردن آن در بخش‌های مختلف) عدم سازماندهی کردن نگرانی‌های پیاده سازی، کار را در پایگاه کد سختتر میکند برای مثال هنگام تغییر منطق تجاری ممکن است مشخص نباشد دقیق کجا باید تغییر کند یا هنگام تغییر ممکن است جاهای مختلفی از کار بیافتد یا منجر به از دست رفتن کدهایی شود که نیاز به اصلاح داشتند. الگوهای معماری اصول سازمانی را برای جنبه‌های مختلف یک پایگاه کد معرفی میکنند و مرزهای واضحی را بین آنها ارائه میکنند: اینکه منطق تجاری چگونه به ورودی، خروجی و سایر اجزای زیرساختی سیستم متصل میشود که بر نحوه تعامل آنها اینکه چه دانشی را به اشتراک می‌گذارند و چگونه مولفه‌ها به یکدیگر ارجاع میکنند تاثیر می‌گذارد. انتخاب روش مناسب جهت سازماندهی پایگاه کد، یا الگوریتم معماری صحیح، برای حمایت از اجرای منطق تجاری در کوتاه مدت و کاهش تعمیر و نگهداری در بلند مدت بسیار مهم است. سه الگوی معماری کاربردی غالب شامل: معماری لایه‌ای، پورت‌ها و آداپتورها، CQRS رو باهم بررسی کنیم
معماری لایه‌ای:
یکی از رایجترین الگوهای معماری می‌باشد که پایکاه کد را در لایه‌های افقی سازماندهی میکند و هر لایه به یکی از نگرانی‌های فنی زیر می‌پردازد که شامل: تعامل با مصرف کنندگان(presentation layer)، منطق تجاری(business logic)، تداوم داده‌ها(data access layer) تصویر اول در کامنت‌ها
لایه تعامل که شامل رابطهای ارتباطی است که میتواند gui,cli,restapi,webui باشد-لایه منطق تجاری که بصورت کپسوله شده است(قلب نرم افزار) الگوها و تصمیمات تجاری در آن است- لایه داده که شامل پایگاه داده است که شکل‌های مختلفی از قبیل پایگاه‌های sql,nosql در شکل های مختلفی از حافظه یا حتی اسناد و داکیومنت مانند باشد. ارتباط این لایه ها باهمدیگه از طریق یک کانال مستقیم از بالا به پایین و ترتیبی است بگونه‌ای که لایه تعامل هیچ درک و خبری از لایه تداوم داده ندارد
در معماری لایه‌ای مشاهده یک لایه اضافه معمول است
لایه سرویس:
لایه سرویس مرز یک برنامه را با لایه ای از خدمات تعریف می کند که مجموعه ای از عملیات موجود را ایجاد می کند و پاسخ برنامه را در هر عملیات هماهنگ می کند.( لایه سرویس به عنوان یک واسطه بین لایه های ارائه برنامه و منطق تجاری عمل می کند)
لایه سرویس در واقع یک مرز منطقی است نه یک سرویس فیزیکی، بعنوان یک نما برای منطق تجاری شناخته میشود که مرز لایه تعامل با منطق تجاری رو جدا میکنه،
داشتن یک لایه سرویس واضح چندین مزیت دارد:
• ما می توانیم از همان لایه سرویس برای سرویس دهی چندین رابط عمومی استفاده مجدد کنیم.
• با جمع آوری تمام روش های مرتبط در یک مکان، ماژولار بودن را بهبود می بخشد.
• لایه های ارائه و منطق تجاری را بیشتر جدا می کند.
• آزمایش عملکرد کسب و کار را آسان تر می کند.
یک لایه سرویس همیشه ضروری نیست. به عنوان مثال، زمانی که منطق کسب و کار به عنوان یک اسکریپت تراکنش پیاده‌سازی میشود، اساساً یک لایه سرویس است، زیرا قبلاً مجموعه‌ای از روش‌ها را که رابط عمومی سیستم را تشکیل می‌دهند، نشان میدهد
از سوی دیگر، اگر الگوی منطق تجاری نیاز به هماهنگی خارجی داشته باشد، لایه سرویس مورد نیاز است، همانطور که در مورد الگوی رکورد فعال وجود دارد. در این مورد، لایه سرویس الگوی اسکریپت تراکنش را پیاده‌سازی میکند، در حالی که رکوردهای فعالی که روی آنها کار میکند در لایه منطق تجاری قرار دارند.
این مورد رو در ذهنتون نگه دارید:
همانگونه که استفاده از الگوهای طراحی بستگی به بزرگی و میزان پیچیدگی دارد، استفاده از لایه سرویس هم بستگی به الگوی طراحی مورد استفاده شده شما در سیستم دارد
اصطلاحات بکار برده شده
اصطلاحات دیگری که در معماری لایه‌ای استفاده میشوند:
• لایه ارائه = لایه رابط کاربر
• لایه سرویس = لایه برنامه
• لایه منطق تجاری = لایه دامنه = لایه مدل
• لایه دسترسی به داده = لایه زیرساخت
#DDD
#domain_driven_desigb
@code_crafters
❤4👍2
این الگو اجرای یک مدل دامنه را چالش برانگیز می کند. در یک مدل دامنه، نهادهای تجاری (تجمیع‌ها و اشیاء ارزشی) نباید هیچ وابستگی و دانشی از زیرساخت های اساسی داشته باشند. وابستگی معماری لایه‌ای از بالا به پایین مستلزم پریدن از میان حلقه‌ها برای برآورده کردن این نیاز است. هنوز هم می توان یک مدل دامنه را در یک معماری لایه ای پیاده سازی کرد
معماری پورت‌ها و آداپتورها:
این معماری بسیار شبیه به معماری لایه‌ای است و پیاده سازی آن ساده است و مناسب‌تر برای منطق‌های تجاری پیچیده است، هر دو لایه ارائه و لایه دسترسی به داده ادغام با مولفه‌های خارجی را نشان می‌دهند: پایگاه داده، خدمات خارجی و چارچوب رابط کاربری این جزییات پیاده سازی منطق تجاری سیستم را منعکس نمی‌کند، پس بیایید تمامی این نگرانی‌های زیرساختی را در یک لایه زیرساختی infrastructure layer یکی کنیم
اصل وارونگی وابستگی DIP:
این اصل بیان میکند که ماژولهای سطح بالا که منطق تجاری رو پیاده سازی میکنند نباید به ماژولهای سطح پایین وابسته باشند(این همان اتفاق ناگواریست که در معماری لایه‌ای به دلیل اصل بالا به پایین رخ میداد به تصویر پست قبلی مجدد نگاه کنید) بیایید رابط را معکوس کنیم تصویر اول در کامنت‌ها در این معماری اکنون منطق تجاری نقش اصلی را برعهده گرفته و نگرانی‌های تکنولوژی حذف شده، با افزودن لایه ارائه به آن تعامل در سیستم برقرار میگردد تصویر دوم در کامنت‌ها این معماری الگوی پورت‌ها و آداپتورها است، منطق تجاری به لایه‌های زیرین وابستگی ندارد، همانطور که برای پیاده سازی مدل دامنه و الگوهای مدل دامنه منبع رویداد لازم است در تصویر سوم در کامنت‌ها دلیل نام گذاری و نحوه یکپارچگی منطق تجاری با اجزای زیرساختی را میبیند
این معماری به عنوان معماری شش ضلعی، معماری پیاز و معماری تمیز نیز شناخته می شود. تمامی این الگوها بر اساس اصول طراحی یکسانی هستند، اجزای یکسانی دارند و روابط یکسانی بین آنها برقرار است، اما در مورد معماری لایه ای، اصطلاحات ممکن است متفاوت باشد:
• لایه کاربردی = لایه سرویس = لایه مورد استفاده
• لایه منطق تجاری = لایه دامنه = لایه اصلی
با وجود این، این الگوها به اشتباه می توانند از نظر مفهومی متفاوت تلقی شوند. این فقط نمونه دیگری از اهمیت یک زبان فراگیر است. جداسازی منطق تجاری از همه نگرانی‌های تکنولوژیکی، معماری پورت‌ها و آداپتورها را مناسب برای منطق تجاری پیاده‌سازی شده با الگوی مدل دامنه می‌سازد.
تفکیک مسئولیت فرمان پرس و جوCQRS:
الگوی (CQRS) بر اساس همان اصول سازمانی برای منطق تجاری و نگرانی های زیرساختی مانند پورت ها و آداپتورها است.با این حال، در نحوه مدیریت داده های سیستم متفاوت است. این الگو نمایش داده های سیستم را در چندین مدل پایدار امکان پذیر می کند.
مدلسازی چندزبانه:
در بسیاری از موارد یک مدل واحد از حوزه تجاری سیستم، برای رفع تمام نیازهای سیستم دشوار باشد برای مثال: پردازش تراکنش آنلاین OLTP و پردازش تحلیلی آنلاین OLAP به نمایش متفاوتی از داده‌های سیستم نیاز دارد.
دلیل دیگر کار با چندین مدل ممکن است به مفهوم تداوم چندزبانه مربوط باشد(هیچ‌پایگاه داده‌ای کامل نیست و هرکدام به روش خود ناقص هستند) ما باید بین پرس و جو، سازگاری و مقیاس تعادل برقرار کنیم. یک راهکار برای یافتن یک پایگاه داده کامل، مدل تداوم چند زبانه است(استفاده از پایگاه‌های اطلاعاتی متعدد برای پیاده‌سازی نیازمندی‌های مرتبط با داده‌های مختلف است)
الگوی CQRS ارتباط نزدیکی با منبع رویداد دارد. در ابتدا، CQRS برای رسیدگی به امکانات محدود پرس و جو یک مدل منبع رویداد تعریف شد: فقط امکان پرس و جو از رویدادهای یک نمونه انبوه در یک زمان وجود دارد. الگوی CQRS امکان تحقق مدلهای پیش‌بینی‌شده را در پایگاه‌های داده فیزیکی فراهم میکند که میتوانند برای گزینه‌های جستجوی انعطاف‌پذیر استفاده شوند. با این حال، این بخش CQRS را از منبع رویداد جدا می کند.حتی اگر منطق تجاری با استفاده از هر یک از الگوهای پیاده سازی منطق تجاری دیگر پیاده سازی شود،CQRS مفید است
پیاده‌سازی:
این الگو مسئولیت مدلهای سیستم را تفکیک میکند. دو نوع مدل وجود دارد:مدل اجرای دستور و مدل های خواندن.
اجرای دستور: CQRS یک مدل واحد را به اجرای عملیاتی اختصاص میدهد که وضعیت سیستم را تغییر میدهد (فرمان های سیستم) این مدل برای پیاده‌سازی منطق تجاری، اعتبارسنجی و اجرای متغیرها استفاده میشود
#DDD
#domain_driven_design
@code_crafters
درک این نکته مهم است که معماری لایه‌ای با معماری N-Tier متفاوت است و این دو بر خلاف تصور همگانی یکی نیستند.
معماری لایه‌ای تفکیک بر اساس مرز منطقی و وظایف برنامه است، اما معماری N-Tier تفکیک بر اساس لایه‌های فیزیکی و امکان مقیاس پذیری و استقرار و نگهداری هر سرویس به شکل جداگانه و توزیع شده است
معماری پورت‌ها و آداپتورها:
این معماری بسیار شبیه به معماری لایه‌ای است و پیاده سازی آن ساده است و مناسب‌تر برای منطق‌های تجاری پیچیده است، هر دو لایه ارائه و لایه دسترسی به داده ادغام با مولفه‌های خارجی را نشان می‌دهند: پایگاه داده، خدمات خارجی و چارچوب رابط کاربری این جزییات پیاده سازی منطق تجاری سیستم را منعکس نمی‌کند، پس بیایید تمامی این نگرانی‌های زیرساختی را در یک لایه زیرساختی infrastructure layer یکی کنیم
اصل وارونگی وابستگی DIP:
این اصل بیان میکند که ماژولهای سطح بالا که منطق تجاری رو پیاده سازی میکنند نباید به ماژولهای سطح پایین وابسته باشند(این همان اتفاق ناگواریست که در معماری لایه‌ای به دلیل اصل بالا به پایین رخ میداد به تصویر پست قبلی مجدد نگاه کنید) بیایید رابط را معکوس کنیم تصویر اول در کامنت‌ها در این معماری اکنون منطق تجاری نقش اصلی را برعهده گرفته و نگرانی‌های تکنولوژی حذف شده، با افزودن لایه ارائه به آن تعامل در سیستم برقرار میگردد تصویر دوم در کامنت‌ها این معماری الگوی پورت‌ها و آداپتورها است، منطق تجاری به لایه‌های زیرین وابستگی ندارد، همانطور که برای پیاده سازی مدل دامنه و الگوهای مدل دامنه منبع رویداد لازم است در تصویر سوم در کامنت‌ها دلیل نام گذاری و نحوه یکپارچگی منطق تجاری با اجزای زیرساختی را میبیند
این معماری به عنوان معماری شش ضلعی، معماری پیاز و معماری تمیز نیز شناخته می شود. تمامی این الگوها بر اساس اصول طراحی یکسانی هستند، اجزای یکسانی دارند و روابط یکسانی بین آنها برقرار است، اما در مورد معماری لایه ای، اصطلاحات ممکن است متفاوت باشد:
• لایه کاربردی = لایه سرویس = لایه مورد استفاده
• لایه منطق تجاری = لایه دامنه = لایه اصلی
با وجود این، این الگوها به اشتباه می توانند از نظر مفهومی متفاوت تلقی شوند. این فقط نمونه دیگری از اهمیت یک زبان فراگیر است. جداسازی منطق تجاری از همه نگرانی‌های تکنولوژیکی، معماری پورت‌ها و آداپتورها را مناسب برای منطق تجاری پیاده‌سازی شده با الگوی مدل دامنه می‌سازد.
تفکیک مسئولیت فرمان پرس و جوCQRS:
الگوی (CQRS) بر اساس همان اصول سازمانی برای منطق تجاری و نگرانی های زیرساختی مانند پورت ها و آداپتورها است.با این حال، در نحوه مدیریت داده های سیستم متفاوت است. این الگو نمایش داده های سیستم را در چندین مدل پایدار امکان پذیر می کند.
مدلسازی چندزبانه:
در بسیاری از موارد یک مدل واحد از حوزه تجاری سیستم، برای رفع تمام نیازهای سیستم دشوار باشد برای مثال: پردازش تراکنش آنلاین OLTP و پردازش تحلیلی آنلاین OLAP به نمایش متفاوتی از داده‌های سیستم نیاز دارد.
دلیل دیگر کار با چندین مدل ممکن است به مفهوم تداوم چندزبانه مربوط باشد(هیچ‌پایگاه داده‌ای کامل نیست و هرکدام به روش خود ناقص هستند) ما باید بین پرس و جو، سازگاری و مقیاس تعادل برقرار کنیم. یک راهکار برای یافتن یک پایگاه داده کامل، مدل تداوم چند زبانه است(استفاده از پایگاه‌های اطلاعاتی متعدد برای پیاده‌سازی نیازمندی‌های مرتبط با داده‌های مختلف است)
الگوی CQRS ارتباط نزدیکی با منبع رویداد دارد. در ابتدا، CQRS برای رسیدگی به امکانات محدود پرس و جو یک مدل منبع رویداد تعریف شد: فقط امکان پرس و جو از رویدادهای یک نمونه انبوه در یک زمان وجود دارد. الگوی CQRS امکان تحقق مدلهای پیش‌بینی‌شده را در پایگاه‌های داده فیزیکی فراهم میکند که میتوانند برای گزینه‌های جستجوی انعطاف‌پذیر استفاده شوند. با این حال، این بخش CQRS را از منبع رویداد جدا می کند.حتی اگر منطق تجاری با استفاده از هر یک از الگوهای پیاده سازی منطق تجاری دیگر پیاده سازی شود،CQRS مفید است
پیاده‌سازی:
این الگو مسئولیت مدلهای سیستم را تفکیک میکند. دو نوع مدل وجود دارد:مدل اجرای دستور و مدل های خواندن.
اجرای دستور: CQRS یک مدل واحد را به اجرای عملیاتی اختصاص میدهد که وضعیت سیستم را تغییر میدهد (فرمان های سیستم) این مدل برای پیاده‌سازی منطق تجاری، اعتبارسنجی و اجرای متغیرها استفاده میشود
#DDD
#domain_driven_design
@code_crafters
❤5
مدل اجرای دستور تنها مدلی است که داده‌های کاملاً سازگار را نشان میدهد(منبع حقیقت سیستم) خواندن وضعیت کاملاً منسجم یک واحد تجاری و پشتیبانی همزمان خوش بینانه هنگام به روز رسانی آن باید امکان پذیر باشد.
مدلهای خواندنی (پیش‌بینی):
سیستم میتواند هر تعداد مدل را برای ارائه داده به کاربران یا ارائه اطلاعات به سیستم‌های دیگر تعریف کند. یک مدل خوانده شده یک پیش بینی، پیش کش است. این می تواند در یک پایگاه داده بادوام، فایل مسطح یا کش درون حافظه قرار گیرد. اجرای صحیح CQRS امکان پاک کردن تمام داده های یک طرح ریزی و بازسازی آن را از ابتدا فراهم می کند. همچنین امکان گسترش سیستم با پیش بینی های اضافی در آینده را فراهم می کند(مدل هایی که در ابتدا نمی توانستند پیش بینی شوند). مدلهای خواندنی فقط خواندنی هستند. هیچ یک از عملیات سیستم نمی تواند مستقیماً داده های مدل های خوانده شده را تغییر دهد.
طرح‌ریزی مدلهای خوانده‌شده:
برای اینکه مدلهای خوانده‌شده کار کنند، سیستم باید تغییرات را از مدل اجرای دستور به همه مدلهای خوانده شده خود پیش‌بینی کند تصویر اول در کامنت‌ها هرگاه جداول منبع بروزرسانی شوند باید در نماهای پیش کش منعکس شود. دو روش برای تولید پیش بینی‌ها:همزمان و ناهمزمان
پیش بینی های همزمان:
پیش بینی های همزمان تغییرات را در داده های OLTP از طریق مدل اشتراک تکمیلی واکشی می کنند:
این فرآیند در شکل 8-13 و به صورت نمودار توالی در شکل 8-14 تصویر دوم در کامنت‌ها نشان داده شده است
پیش‌بینی‌های ناهمزمان:
در سناریوی پیش‌بینی ناهمزمان، مدل اجرای دستور همه تغییرات متعهد را در یک گذرگاه پیام منتشر میکند. موتورهای پروجکشن سیستم می توانند در پیام های منتشر شده مشترک شوند و از آنها برای به روز رسانی مدل های خوانده شده استفاده کنند. تصویر سوم در کامنت
علیرغم مزایای مقیاس‌گذاری و عملکرد آشکار روش پیش‌بینی ناهمزمان، این روش بیشتر مستعد چالش‌های محاسبات توزیع‌شده است. اگر پیام‌ها نامرتب یا تکراری پردازش شوند، داده‌های متناقض در مدلهای خوانده شده نمایش داده میشوند. این روش همچنین افزودن پیش بینی های جدید یا بازسازی پیش بینی های موجود را چالش برانگیزتر می کند. به این دلایل، توصیه می شود همیشه طرح ریزی همزمان و به صورت اختیاری، یک طرح غیرهمزمان اضافی در بالای آن اجرا شود
تفکیک مدل در معماری CQRS:
مسئولیت های مدل های سیستم بر اساس نوع آنها تفکیک می شود. یک فرمان فقط می تواند بر روی مدل اجرای دستور به شدت سازگار عمل کند. یک پرس و جو نمی تواند مستقیماً هیچ یک از حالت های پایدار سیستم را تغییر دهد(نه مدل های خوانده شده و نه مدل اجرای دستور) یک تصور غلط رایج در مورد سیستم های مبتنی بر CQRS این است که یک فرمان فقط می تواند داده ها را تغییر دهد و داده ها را می توان برای نمایش فقط از طریق یک مدل خواندنی واکشی کرد.به عبارت دیگر، دستور اجرای متدها هرگز نباید هیچ داده ای را برگرداند، این اشتباه است. این رویکرد پیچیدگی های تصادفی ایجاد می کند و منجر به تجربه کاربری بدی می شود. یک فرمان همیشه باید به تماس گیرنده اطلاع دهد که آیا موفق بوده یا ناموفق. اگر شکست خورده است، چرا شکست خورده است؟ آیا اعتبار یا مشکل فنی وجود داشت؟ تماس گیرنده باید بداند که چگونه دستور را برطرف کند. بنابراین، یک فرمان می تواند(در بسیاری از موارد باید) داده ها را برگرداند. برای مثال: اگر رابط کاربری سیستم باید تغییرات حاصل از دستور را منعکس کند. این نه تنها کار کردن با سیستم را برای مشتریان آسان‌تر میکند، منجر میشود بلافاصله بازخورد اقدامات خود را دریافت کنند، و مقادیر برگشتی را میتوان بیشتر در جریان کاری مصرف‌کنندگان مورد استفاده قرار داد و نیاز به رفت و برگشت داده‌های غیرضروری را از بین می‌برد. تنها محدودیت در اینجا این است که داده‌های برگشتی باید از مدل کاملاً سازگار یا مدل اجرای دستور منشأ بگیرند، زیرا نمی‌توانیم انتظار داشته باشیم که پیش‌بینی‌ها، که در نهایت سازگار خواهند بود، فوراً به‌روزرسانی شوند.
#DDD
#domain_driven_design
@code_crafters
مدلهای خواندنی (پیش‌بینی):
سیستم میتواند هر تعداد مدل را برای ارائه داده به کاربران یا ارائه اطلاعات به سیستم‌های دیگر تعریف کند. یک مدل خوانده شده یک پیش بینی، پیش کش است. این می تواند در یک پایگاه داده بادوام، فایل مسطح یا کش درون حافظه قرار گیرد. اجرای صحیح CQRS امکان پاک کردن تمام داده های یک طرح ریزی و بازسازی آن را از ابتدا فراهم می کند. همچنین امکان گسترش سیستم با پیش بینی های اضافی در آینده را فراهم می کند(مدل هایی که در ابتدا نمی توانستند پیش بینی شوند). مدلهای خواندنی فقط خواندنی هستند. هیچ یک از عملیات سیستم نمی تواند مستقیماً داده های مدل های خوانده شده را تغییر دهد.
طرح‌ریزی مدلهای خوانده‌شده:
برای اینکه مدلهای خوانده‌شده کار کنند، سیستم باید تغییرات را از مدل اجرای دستور به همه مدلهای خوانده شده خود پیش‌بینی کند تصویر اول در کامنت‌ها هرگاه جداول منبع بروزرسانی شوند باید در نماهای پیش کش منعکس شود. دو روش برای تولید پیش بینی‌ها:همزمان و ناهمزمان
پیش بینی های همزمان:
پیش بینی های همزمان تغییرات را در داده های OLTP از طریق مدل اشتراک تکمیلی واکشی می کنند:
• موتور طرح ریزی پایگاه داده OLTP را برای سوابق اضافه یا به روز شده پس از آخرین نقطه بازرسی پردازش شده جستجو می کند.
• موتور پروژکتور از داده های به روز شده برای بازسازی/به روز رسانی مدل های خوانده شده سیستم استفاده می کند.
• موتور پروژکتور نقطه بازرسی آخرین رکورد پردازش شده را ذخیره می کند. این مقدار در تکرار بعدی برای افزودن یا اصلاح رکوردها پس از آخرین رکورد پردازش شده استفاده خواهد شد.
این فرآیند در شکل 8-13 و به صورت نمودار توالی در شکل 8-14 تصویر دوم در کامنت‌ها نشان داده شده است
پیش‌بینی‌های ناهمزمان:
در سناریوی پیش‌بینی ناهمزمان، مدل اجرای دستور همه تغییرات متعهد را در یک گذرگاه پیام منتشر میکند. موتورهای پروجکشن سیستم می توانند در پیام های منتشر شده مشترک شوند و از آنها برای به روز رسانی مدل های خوانده شده استفاده کنند. تصویر سوم در کامنت
علیرغم مزایای مقیاس‌گذاری و عملکرد آشکار روش پیش‌بینی ناهمزمان، این روش بیشتر مستعد چالش‌های محاسبات توزیع‌شده است. اگر پیام‌ها نامرتب یا تکراری پردازش شوند، داده‌های متناقض در مدلهای خوانده شده نمایش داده میشوند. این روش همچنین افزودن پیش بینی های جدید یا بازسازی پیش بینی های موجود را چالش برانگیزتر می کند. به این دلایل، توصیه می شود همیشه طرح ریزی همزمان و به صورت اختیاری، یک طرح غیرهمزمان اضافی در بالای آن اجرا شود
تفکیک مدل در معماری CQRS:
مسئولیت های مدل های سیستم بر اساس نوع آنها تفکیک می شود. یک فرمان فقط می تواند بر روی مدل اجرای دستور به شدت سازگار عمل کند. یک پرس و جو نمی تواند مستقیماً هیچ یک از حالت های پایدار سیستم را تغییر دهد(نه مدل های خوانده شده و نه مدل اجرای دستور) یک تصور غلط رایج در مورد سیستم های مبتنی بر CQRS این است که یک فرمان فقط می تواند داده ها را تغییر دهد و داده ها را می توان برای نمایش فقط از طریق یک مدل خواندنی واکشی کرد.به عبارت دیگر، دستور اجرای متدها هرگز نباید هیچ داده ای را برگرداند، این اشتباه است. این رویکرد پیچیدگی های تصادفی ایجاد می کند و منجر به تجربه کاربری بدی می شود. یک فرمان همیشه باید به تماس گیرنده اطلاع دهد که آیا موفق بوده یا ناموفق. اگر شکست خورده است، چرا شکست خورده است؟ آیا اعتبار یا مشکل فنی وجود داشت؟ تماس گیرنده باید بداند که چگونه دستور را برطرف کند. بنابراین، یک فرمان می تواند(در بسیاری از موارد باید) داده ها را برگرداند. برای مثال: اگر رابط کاربری سیستم باید تغییرات حاصل از دستور را منعکس کند. این نه تنها کار کردن با سیستم را برای مشتریان آسان‌تر میکند، منجر میشود بلافاصله بازخورد اقدامات خود را دریافت کنند، و مقادیر برگشتی را میتوان بیشتر در جریان کاری مصرف‌کنندگان مورد استفاده قرار داد و نیاز به رفت و برگشت داده‌های غیرضروری را از بین می‌برد. تنها محدودیت در اینجا این است که داده‌های برگشتی باید از مدل کاملاً سازگار یا مدل اجرای دستور منشأ بگیرند، زیرا نمی‌توانیم انتظار داشته باشیم که پیش‌بینی‌ها، که در نهایت سازگار خواهند بود، فوراً به‌روزرسانی شوند.
#DDD
#domain_driven_design
@code_crafters
❤5
زمان استفاده از CQRS:
الگوی CQRS میتواند برای برنامه‌هایی مفید باشد که نیاز به کار با داده‌های یکسان در مدلهای متعدد دارند که احتمالاً در انواع مختلف پایگاه‌های داده ذخیره میشوند. از منظر عملیاتی، این الگو از ارزش اصلی طراحی دامنه محور یعنی کار با موثرترین مدل ها برای کار در دست، و بهبود مستمر مدل حوزه کسب و کار پشتیبانی می کند. از منظر زیرساختی، CQRS امکان استفاده از قدرت انواع مختلف پایگاه‌های داده را فراهم میکند. برای مثال، استفاده از یک پایگاه داده رابطهای برای ذخیره‌سازی مدل اجرای دستور، یک فهرست جستجو برای جستجوی متن کامل، و فایل‌های مسطح از پیش اجرا شده برای بازیابی سریع داده‌ها، با همه مکانیسم‌های ذخیره‌سازی به طور قابل اعتماد همگام‌سازی شده‌اند.
علاوه بر این، CQRS به طور طبیعی خود را به مدل های دامنه منبع رویداد (وام/قرض) می دهد. مدل منبع رویداد امکان پرس‌وجو از رکوردها را بر اساس وضعیت‌های تجمیع‌ها غیرممکن میکند، اما CQRS این کار را با نمایش وضعیت‌ها در پایگاه‌های داده قابل پرسش امکان‌پذیر میکند.
محدوده scope:
دامنه الگوهایی که در مورد آنها بحث کردیم(معماری لایه‌ای، معماری پورت‌ها و آداپتورها و CQRS ) نباید به عنوان اصول سازمانی در سراسر سیستم تلقی شوند. اینها لزوماً الگوهای معماری سطح بالا برای یک بافت محدود نیز نیستند. تصویر اول در کامنت
یک بافت محدود شامل چندین زیر دامنه را در نظر بگیرید. زیر دامنه ها می توانند انواع مختلفی داشته باشند: هسته ای، پشتیبانی کننده یا عمومی.
حتی زیر دامنه‌های هم نوع ممکن است به منطق تجاری و الگوهای معماری متفاوتی نیاز داشته باشند. اجرای یک معماری منفرد، محدود و گسترده، به طور ناخواسته منجر به پیچیدگی تصادفی خواهد شد. بافت‌های محدودی که چندین زیر دامنه را در بر می گیرد هدف ما هدایت تصمیمات طراحی بر اساس نیازهای واقعی و استراتژی تجاری است. علاوه بر لایه هایی که سیستم را به صورت افقی پارتیشن بندی می کنند، می توانیم پارتیشن بندی عمودی اضافی را معرفی کنیم. تصویر دوم در کامنت تعیین مرزهای منطقی برای ماژول هایی که زیر دامنه های تجاری متمایز را در خود محصور می کنند و استفاده از ابزارهای مناسب برای هر کدام بسیار مهم است. مرزهای عمودی مناسب یک بافت محدود یکپارچه را مدولار می کند و به جلوگیری از تبدیل شدن آن به یک توپ بزرگ از گل کمک می کند. این مرزهای منطقی را می توان بعداً به مرزهای فیزیکی بافت های مرزی با دانه بندی ریزتر تبدیل کرد.
#DDD
#domain_driven_design
@code_crafters
الگوی CQRS میتواند برای برنامه‌هایی مفید باشد که نیاز به کار با داده‌های یکسان در مدلهای متعدد دارند که احتمالاً در انواع مختلف پایگاه‌های داده ذخیره میشوند. از منظر عملیاتی، این الگو از ارزش اصلی طراحی دامنه محور یعنی کار با موثرترین مدل ها برای کار در دست، و بهبود مستمر مدل حوزه کسب و کار پشتیبانی می کند. از منظر زیرساختی، CQRS امکان استفاده از قدرت انواع مختلف پایگاه‌های داده را فراهم میکند. برای مثال، استفاده از یک پایگاه داده رابطهای برای ذخیره‌سازی مدل اجرای دستور، یک فهرست جستجو برای جستجوی متن کامل، و فایل‌های مسطح از پیش اجرا شده برای بازیابی سریع داده‌ها، با همه مکانیسم‌های ذخیره‌سازی به طور قابل اعتماد همگام‌سازی شده‌اند.
علاوه بر این، CQRS به طور طبیعی خود را به مدل های دامنه منبع رویداد (وام/قرض) می دهد. مدل منبع رویداد امکان پرس‌وجو از رکوردها را بر اساس وضعیت‌های تجمیع‌ها غیرممکن میکند، اما CQRS این کار را با نمایش وضعیت‌ها در پایگاه‌های داده قابل پرسش امکان‌پذیر میکند.
محدوده scope:
دامنه الگوهایی که در مورد آنها بحث کردیم(معماری لایه‌ای، معماری پورت‌ها و آداپتورها و CQRS ) نباید به عنوان اصول سازمانی در سراسر سیستم تلقی شوند. اینها لزوماً الگوهای معماری سطح بالا برای یک بافت محدود نیز نیستند. تصویر اول در کامنت
یک بافت محدود شامل چندین زیر دامنه را در نظر بگیرید. زیر دامنه ها می توانند انواع مختلفی داشته باشند: هسته ای، پشتیبانی کننده یا عمومی.
حتی زیر دامنه‌های هم نوع ممکن است به منطق تجاری و الگوهای معماری متفاوتی نیاز داشته باشند. اجرای یک معماری منفرد، محدود و گسترده، به طور ناخواسته منجر به پیچیدگی تصادفی خواهد شد. بافت‌های محدودی که چندین زیر دامنه را در بر می گیرد هدف ما هدایت تصمیمات طراحی بر اساس نیازهای واقعی و استراتژی تجاری است. علاوه بر لایه هایی که سیستم را به صورت افقی پارتیشن بندی می کنند، می توانیم پارتیشن بندی عمودی اضافی را معرفی کنیم. تصویر دوم در کامنت تعیین مرزهای منطقی برای ماژول هایی که زیر دامنه های تجاری متمایز را در خود محصور می کنند و استفاده از ابزارهای مناسب برای هر کدام بسیار مهم است. مرزهای عمودی مناسب یک بافت محدود یکپارچه را مدولار می کند و به جلوگیری از تبدیل شدن آن به یک توپ بزرگ از گل کمک می کند. این مرزهای منطقی را می توان بعداً به مرزهای فیزیکی بافت های مرزی با دانه بندی ریزتر تبدیل کرد.
#DDD
#domain_driven_design
@code_crafters
❤6
الگوهای طراحی تاکتیکی راه‌های مختلف پیاده‌سازی اجزای یک سیستم را تعریف میکند: (نحوه مدلسازی منطق کسب‌وکار و نحوه سازماندهی داخلی یک بافت محدود از نظر معماری) در ادامه، ما از مرزهای یک جزء فراتر می رویم و الگوهای سازماندهی جریان ارتباطات در بین عناصر یک سیستم را مورد بحث قرار می دهیم. الگوهایی که ارتباطات بافتی متقابل را تسهیل میکنند، به محدودیت‌های تحمیل‌شده توسط اصول طراحی تجمیع می‌پردازند، و فرآیندهای کسب‌وکار را که شامل اجزای سیستم متعددی میشوند، هماهنگ میکنند.
ترجمه مدل یک بافت محدود، مرز مدل یک زبان فراگیر است، الگوهای مختلفی رو برای طراحی ارتباطات در بافت‌های محدود مختلفی یاد گرفتیم جهت یادآوری: در دو بافت محدود (ادغام سازی، اشتراک هسته) و در یک رابطه مشتری-تامین‌کننده با ترجمه مدلهای بافت محدود ارتباط را تسهیل کرد(ترجمه توسط بافت محدود پایین دست -مصرف کننده- بوسیله لایه ضد فساد ACL یا ترجمه توسط بافت محدود بالادست-تامین کننده- بوسیله میزبان باز OHS)
منطق ترجمه مدل میتواند بدون حالت یا با حالت باشد ترجمه بدون حالت مانند OHS/ACL صادر میشود، در حالیکه ترجمه حالت دار شامل نطق ترجمه پیچیده تری است که به پایگاه داده نیاز دارد
ترجمه مدل بدون حالت(بی تابعیت):
بافت محدودی که ترجمه را در اختیار دارد (OHS برای بالادست، ACL برای پایین‌دست) الگوی طراحی پراکسی را برای مداخله درخواست‌های ورودی و خروجی و ترسیم مدل منبع به مدل هدف بافت محدود پیاده‌سازی میکند
(request --> proxy --> target)
پیاده سازی پروکسی به این بستگی دارد که آیا بافت‌های محدود به صورت همزمان یا ناهمزمان با هم ارتباط برقرار می کنند
همزمان:
روش معمولی برای ترجمه مدل های مورد استفاده در ارتباطات همزمان، جاسازی منطق تبدیل در پایگاه کد بافت محدود است، تصویر اول در کامنت در یک سرویس میزبان باز، ترجمه به زبان عمومی هنگام پردازش درخواست‌های دریافتی انجام میشود، و در یک لایه ضد فساد، هنگام فراخوانی بافت محدود بالادستی اتفاق می‌افتد. در برخی موارد، بارگذاری منطق ترجمه به یک مؤلفه خارجی مانند الگوی دروازه API می تواند مقرون به صرفه تر و راحت تر باشد. مؤلفه دروازه API می تواند یک راه حل مبتنی بر نرم افزار منبع باز باشد، یا می تواند یک سرویس مدیریت شده یک فروشنده ابری باشد. برای بافت‌های محدودی که الگوی میزبان باز OHS را پیاده‌سازی میکنند، دروازه API مسئول تبدیل مدل داخلی به زبان منتشر شده با بهینه‌سازی ادغام است. علاوه بر این، داشتن یک دروازه API صریح میتواند فرآیند مدیریت و ارائه نسخه‌های متعدد از API بافت محدود را کاهش دهد تصویر دوم در کامنت
لایه‌های ضد فساد پیاده‌سازی شده با استفاده از یک دروازه API میتوانند توسط چندین بافت محدود پایین دست مصرف شوند. تصویر سوم در کامنت در چنین مواردی، لایه ضد فساد به عنوان یک بافت محدود خاص یکپارچه سازی عمل می کند. لایه مشترک ضد فساد چنین بافت‌های محدود، که عمدتاً مسئول تغییر مدل‌ها برای مصرف راحت‌تر توسط سایر مؤلفه‌ها هستند، اغلب به عنوان بافت‌های تبادلی نامیده میشوند.
ناهمزمان:
برای ترجمه مدلهای مورد استفاده در ارتباطات ناهمزمان، می‌توانید یک پروکسی پیام را پیاده‌سازی کنید: یک جزء واسطه که مشترک پیام‌هایی است که از بافت محدود منبع می‌آیند. پروکسی تبدیل‌های مدل مورد نیاز را اعمال می کند و پیام های حاصل را به مشترک هدف ارسال میکند تصویر چهارم در کامنت علاوه بر ترجمه مدل پیام‌ها، مؤلفه رهگیری همچنین میتواند با فیلتر کردن پیام‌های نامربوط، نویز را در بافت محدود هدف کاهش دهد. ترجمه مدل ناهمزمان هنگام اجرای یک سرویس میزبان باز ضروری است. این یک اشتباه رایج است که یک زبان منتشر شده را برای اشیاء مدل طراحی و در معرض دید قرار دهیم و اجازه دهیم رویدادهای دامنه همانطور که هستند منتشر شوند، در نتیجه مدل پیاده‌سازی بافت محدود را نشان میدهد. ترجمه ناهمزمان را می توان برای رهگیری رویدادهای دامنه و تبدیل آنها به یک زبان منتشر شده مورد استفاده قرار داد، بنابراین کپسوله سازی بهتری از جزئیات پیاده سازی بافت محدود را فراهم می کند، تصویر پنجم در کامنت علاوه بر این، ترجمه پیام ها به زبان منتشر شده، تمایز بین رویدادهای خصوصی را که برای نیازهای داخلی بافت محدود در نظر گرفته شده اند و رویدادهای عمومی که برای ادغام با سایر بافت‌های محدود طراحی شده اند، امکان پذیر می کند
#DDD
#domain_driven_design
@code_crafters
ترجمه مدل یک بافت محدود، مرز مدل یک زبان فراگیر است، الگوهای مختلفی رو برای طراحی ارتباطات در بافت‌های محدود مختلفی یاد گرفتیم جهت یادآوری: در دو بافت محدود (ادغام سازی، اشتراک هسته) و در یک رابطه مشتری-تامین‌کننده با ترجمه مدلهای بافت محدود ارتباط را تسهیل کرد(ترجمه توسط بافت محدود پایین دست -مصرف کننده- بوسیله لایه ضد فساد ACL یا ترجمه توسط بافت محدود بالادست-تامین کننده- بوسیله میزبان باز OHS)
منطق ترجمه مدل میتواند بدون حالت یا با حالت باشد ترجمه بدون حالت مانند OHS/ACL صادر میشود، در حالیکه ترجمه حالت دار شامل نطق ترجمه پیچیده تری است که به پایگاه داده نیاز دارد
ترجمه مدل بدون حالت(بی تابعیت):
بافت محدودی که ترجمه را در اختیار دارد (OHS برای بالادست، ACL برای پایین‌دست) الگوی طراحی پراکسی را برای مداخله درخواست‌های ورودی و خروجی و ترسیم مدل منبع به مدل هدف بافت محدود پیاده‌سازی میکند
(request --> proxy --> target)
پیاده سازی پروکسی به این بستگی دارد که آیا بافت‌های محدود به صورت همزمان یا ناهمزمان با هم ارتباط برقرار می کنند
همزمان:
روش معمولی برای ترجمه مدل های مورد استفاده در ارتباطات همزمان، جاسازی منطق تبدیل در پایگاه کد بافت محدود است، تصویر اول در کامنت در یک سرویس میزبان باز، ترجمه به زبان عمومی هنگام پردازش درخواست‌های دریافتی انجام میشود، و در یک لایه ضد فساد، هنگام فراخوانی بافت محدود بالادستی اتفاق می‌افتد. در برخی موارد، بارگذاری منطق ترجمه به یک مؤلفه خارجی مانند الگوی دروازه API می تواند مقرون به صرفه تر و راحت تر باشد. مؤلفه دروازه API می تواند یک راه حل مبتنی بر نرم افزار منبع باز باشد، یا می تواند یک سرویس مدیریت شده یک فروشنده ابری باشد. برای بافت‌های محدودی که الگوی میزبان باز OHS را پیاده‌سازی میکنند، دروازه API مسئول تبدیل مدل داخلی به زبان منتشر شده با بهینه‌سازی ادغام است. علاوه بر این، داشتن یک دروازه API صریح میتواند فرآیند مدیریت و ارائه نسخه‌های متعدد از API بافت محدود را کاهش دهد تصویر دوم در کامنت
لایه‌های ضد فساد پیاده‌سازی شده با استفاده از یک دروازه API میتوانند توسط چندین بافت محدود پایین دست مصرف شوند. تصویر سوم در کامنت در چنین مواردی، لایه ضد فساد به عنوان یک بافت محدود خاص یکپارچه سازی عمل می کند. لایه مشترک ضد فساد چنین بافت‌های محدود، که عمدتاً مسئول تغییر مدل‌ها برای مصرف راحت‌تر توسط سایر مؤلفه‌ها هستند، اغلب به عنوان بافت‌های تبادلی نامیده میشوند.
ناهمزمان:
برای ترجمه مدلهای مورد استفاده در ارتباطات ناهمزمان، می‌توانید یک پروکسی پیام را پیاده‌سازی کنید: یک جزء واسطه که مشترک پیام‌هایی است که از بافت محدود منبع می‌آیند. پروکسی تبدیل‌های مدل مورد نیاز را اعمال می کند و پیام های حاصل را به مشترک هدف ارسال میکند تصویر چهارم در کامنت علاوه بر ترجمه مدل پیام‌ها، مؤلفه رهگیری همچنین میتواند با فیلتر کردن پیام‌های نامربوط، نویز را در بافت محدود هدف کاهش دهد. ترجمه مدل ناهمزمان هنگام اجرای یک سرویس میزبان باز ضروری است. این یک اشتباه رایج است که یک زبان منتشر شده را برای اشیاء مدل طراحی و در معرض دید قرار دهیم و اجازه دهیم رویدادهای دامنه همانطور که هستند منتشر شوند، در نتیجه مدل پیاده‌سازی بافت محدود را نشان میدهد. ترجمه ناهمزمان را می توان برای رهگیری رویدادهای دامنه و تبدیل آنها به یک زبان منتشر شده مورد استفاده قرار داد، بنابراین کپسوله سازی بهتری از جزئیات پیاده سازی بافت محدود را فراهم می کند، تصویر پنجم در کامنت علاوه بر این، ترجمه پیام ها به زبان منتشر شده، تمایز بین رویدادهای خصوصی را که برای نیازهای داخلی بافت محدود در نظر گرفته شده اند و رویدادهای عمومی که برای ادغام با سایر بافت‌های محدود طراحی شده اند، امکان پذیر می کند
#DDD
#domain_driven_design
@code_crafters
❤3
ترجمه مدل Stateful:
برای تبدیل مدل های مهم تر برای مثال: زمانی که مکانیسم ترجمه باید داده های منبع را جمع کند یا داده ها را از چندین منبع در یک مدل واحد متحد کند، ممکن است به یک ترجمه حالتی نیاز باشد. اجازه دهید در مورد هر یک از این موارد استفاده صحبت کنیم
جمع‌آوری داده‌های ورودی:
فرض کنید یک بافت محدود علاقمند به جمع‌آوری درخواست‌های ورودی و پردازش آنها به صورت دسته‌ای برای بهینه‌سازی عملکرد است. در این مورد، ممکن است برای درخواست‌های همزمان و ناهمزمان به تجمیع نیاز باشد تصویر اول در کامنت درخواست‌های دسته‌بندی یکی دیگر از موارد استفاده رایج برای تجمیع داده‌های منبع، ترکیب چندین پیام ریزدانه در یک پیام واحد حاوی داده‌های یکپارچه است، همانطور که تصویر دوم در کامنت نشان داده شده است
تبدیل مدلی که داده های ورودی را جمع می کند، نمی تواند با استفاده از یک دروازه API پیاده سازی شود، و بنابراین نیاز به پردازش دقیق تر و حالت دار دارد. منطق ترجمه برای ردیابی داده های دریافتی و پردازش آنها بر اساس آن، به ذخیره سازی دائمی خود نیاز دارد تصویر سوم در کامنت
یکپارچه سازی چندین منبع:
یک بافت محدود ممکن است نیاز به پردازش انبوه داده ها از چندین منبع، از جمله سایر بافت‌های محدود داشته باشد.یک مثال معمولی برای این الگوی backend-for-frontend است، که در آن رابط کاربر باید داده های منشأ گرفته از چندین سرویس را ترکیب کند. مثال دیگر یک بافت محدود است که باید داده ها را از چندین بافت دیگر پردازش کند و منطق تجاری پیچیده را برای پردازش همه داده ها پیاده سازی کند. در این مورد، جدا کردن پیچیدگی‌های یکپارچه‌سازی و منطق کسب‌وکار با قرار دادن بافت محدود با یک لایه ضد فساد که داده‌ها را از همه بافت‌های محدود دیگر جمع‌آوری میکند، میتواند سودمند باشد. تصویر چهارم در کامنت
صندوق خروجی:
الگوی صندوق خروجی تصویر پنجم در کامنت انتشار قابل اعتماد رویدادهای دامنه را با استفاده از الگوریتم زیر تضمین می کند:
حماسه(saga):
یکی از اصول اصلی طراحی تجمیع این است که هر تراکنش را به یک نمونه از یک تجمیع محدود کنیم. این تضمین می کند که مرزهای یک تجمیع به دقت در نظر گرفته شده و مجموعه منسجمی از عملکردهای تجاری را در بر می‌گیرد. اما مواردی وجود دارد که شما باید یک فرآیند تجاری را پیاده سازی کنید که چندین تجمیع را در بر می گیرد.
برای مثال: یک کمپین تبلیغاتی را در نظر بگیرید که شامل درخواست، دریافت، رد، تایید و انتشار تبلیغ می‌باشد
این جریان شامل دو نهاد تجاری است: کمپین تبلیغاتی و ناشر. قرار دادن واحدهای تجاری در یک مرز تجمیع یکسان قطعاً بیش از حد خواهد بود، زیرا اینها به وضوح نهادهای تجاری متفاوتی هستند که مسئولیتهای متفاوتی دارند و ممکن است به زمینه‌های محدود متفاوتی تعلق داشته باشند. در عوض، این جریان می تواند به عنوان یک حماسه اجرا شود.
#DDD
#domain_driven_design
@code_crafters
برای تبدیل مدل های مهم تر برای مثال: زمانی که مکانیسم ترجمه باید داده های منبع را جمع کند یا داده ها را از چندین منبع در یک مدل واحد متحد کند، ممکن است به یک ترجمه حالتی نیاز باشد. اجازه دهید در مورد هر یک از این موارد استفاده صحبت کنیم
جمع‌آوری داده‌های ورودی:
فرض کنید یک بافت محدود علاقمند به جمع‌آوری درخواست‌های ورودی و پردازش آنها به صورت دسته‌ای برای بهینه‌سازی عملکرد است. در این مورد، ممکن است برای درخواست‌های همزمان و ناهمزمان به تجمیع نیاز باشد تصویر اول در کامنت درخواست‌های دسته‌بندی یکی دیگر از موارد استفاده رایج برای تجمیع داده‌های منبع، ترکیب چندین پیام ریزدانه در یک پیام واحد حاوی داده‌های یکپارچه است، همانطور که تصویر دوم در کامنت نشان داده شده است
تبدیل مدلی که داده های ورودی را جمع می کند، نمی تواند با استفاده از یک دروازه API پیاده سازی شود، و بنابراین نیاز به پردازش دقیق تر و حالت دار دارد. منطق ترجمه برای ردیابی داده های دریافتی و پردازش آنها بر اساس آن، به ذخیره سازی دائمی خود نیاز دارد تصویر سوم در کامنت
یکپارچه سازی چندین منبع:
یک بافت محدود ممکن است نیاز به پردازش انبوه داده ها از چندین منبع، از جمله سایر بافت‌های محدود داشته باشد.یک مثال معمولی برای این الگوی backend-for-frontend است، که در آن رابط کاربر باید داده های منشأ گرفته از چندین سرویس را ترکیب کند. مثال دیگر یک بافت محدود است که باید داده ها را از چندین بافت دیگر پردازش کند و منطق تجاری پیچیده را برای پردازش همه داده ها پیاده سازی کند. در این مورد، جدا کردن پیچیدگی‌های یکپارچه‌سازی و منطق کسب‌وکار با قرار دادن بافت محدود با یک لایه ضد فساد که داده‌ها را از همه بافت‌های محدود دیگر جمع‌آوری میکند، میتواند سودمند باشد. تصویر چهارم در کامنت
صندوق خروجی:
الگوی صندوق خروجی تصویر پنجم در کامنت انتشار قابل اعتماد رویدادهای دامنه را با استفاده از الگوریتم زیر تضمین می کند:
• هم وضعیت کل به روز شده و هم رویدادهای دامنه جدید در یک تراکنش اتمی انجام می شوند.
• یک رله پیام واکشی رویدادهای دامنه جدید از پایگاه داده.
• رله رویدادهای دامنه را در گذرگاه پیام منتشر می کند.
• پس از انتشار موفقیت آمیز، رله یا رویدادها را به عنوان منتشر شده در پایگاه داده علامت گذاری می کند یا آنها را به طور کامل حذف می کند.
حماسه(saga):
یکی از اصول اصلی طراحی تجمیع این است که هر تراکنش را به یک نمونه از یک تجمیع محدود کنیم. این تضمین می کند که مرزهای یک تجمیع به دقت در نظر گرفته شده و مجموعه منسجمی از عملکردهای تجاری را در بر می‌گیرد. اما مواردی وجود دارد که شما باید یک فرآیند تجاری را پیاده سازی کنید که چندین تجمیع را در بر می گیرد.
برای مثال: یک کمپین تبلیغاتی را در نظر بگیرید که شامل درخواست، دریافت، رد، تایید و انتشار تبلیغ می‌باشد
این جریان شامل دو نهاد تجاری است: کمپین تبلیغاتی و ناشر. قرار دادن واحدهای تجاری در یک مرز تجمیع یکسان قطعاً بیش از حد خواهد بود، زیرا اینها به وضوح نهادهای تجاری متفاوتی هستند که مسئولیتهای متفاوتی دارند و ممکن است به زمینه‌های محدود متفاوتی تعلق داشته باشند. در عوض، این جریان می تواند به عنوان یک حماسه اجرا شود.
#DDD
#domain_driven_design
@code_crafters
❤4
یک فرآیند تجاری طولانی مدت است. این امر نه لزوماً از نظر زمانی، زیرا حماسه‌ها میتوانند از چند ثانیه تا چند سال اجرا شوند، بلکه از نظر تراکنش‌ها: یک فرآیند تجاری که چندین تراکنش را در بر می‌گیرد. تراکنش‌ها نه تنها توسط تجمیع‌ها، بلکه توسط هر مؤلفه‌ای که رویدادهای دامنه را منتشر میکند و به دستورات پاسخ میدهد قابل رسیدگی است. حماسه به وقایع منتشر شده توسط اجزای مربوطه گوش می دهد و دستورات بعدی را برای سایر اجزا صادر می کند. اگر یکی از مراحل اجرا ناموفق باشد، حماسه مسئول صدور اقدامات جبرانی مربوطه برای اطمینان از ثابت ماندن وضعیت سیستم است تصویر اول در کامنت
سازگاری:
اگرچه الگوی حماسه یک تراکنش چند جزئی را تنظیم می کند، حالات اجزای درگیر در نهایت سازگار است. و اگرچه حماسه در نهایت دستورات مربوطه را اجرا می کند، هیچ دو تراکنشی را نمی توان اتمی در نظر گرفت.
این با یکی دیگر از اصول طراحی کل مرتبط است:
فقط داده‌های درون مرزهای یک تجمیع را میتوان به شدت سازگار در نظر گرفت.
همه چیز بیرون در نهایت سازگار است.
از این به عنوان یک اصل راهنما استفاده کنید تا مطمئن شوید که از حماسه ها برای جبران مرزهای نادرست کل سوء استفاده نمی کنید. عملیات تجاری که باید به یک تجمیع تعلق داشته باشند به داده های کاملاً سازگار نیاز دارند.
الگوی حماسه اغلب با الگوی دیگری اشتباه گرفته می شود: مدیر فرآیند. اگرچه پیاده سازی مشابه است، اما این الگوهای متفاوتی هستند.
مدیر فرآیند:
الگوی حماسه جریان ساده و خطی را مدیریت می کند. به بیان دقیق، یک حماسه رویدادها را با دستورات مربوطه مطابقت می دهد. در مثال‌هایی که برای نشان دادن پیاده‌سازی حماسه استفاده کردیم، در واقع تطبیق ساده رویدادها با دستورات را پیاده‌سازی کردیم:
الگوی مدیر فرآیند، تصویر دوم در کامنت نشان داده شده است، برای اجرای یک فرآیند مبتنی بر منطق تجاری در نظر گرفته شده است. این به عنوان یک واحد پردازش مرکزی تعریف می شود که وضعیت توالی را حفظ می کند و مراحل پردازش بعدی را تعیین می کند.
به عنوان یک قانون ساده، اگر یک حماسه حاوی عبارات if-else برای انتخاب مسیر صحیح عمل باشد، احتمالاً یک مدیر فرآیند است. تفاوت دیگر بین یک مدیر فرآیند و یک حماسه این است که یک حماسه به طور ضمنی با مشاهده یک رویداد خاص، نمونه‌سازی میشود. از طرف دیگر، یک مدیر فرآیند نمی تواند به یک رویداد منبع واحد محدود شود. در عوض، این یک فرآیند تجاری منسجم است که از چند مرحله تشکیل شده است. از این رو، یک مدیر فرآیند باید به صراحت معرفی شود. به مثال زیر توجه کنید:
رزرو یک سفر کاری با الگوریتم مسیریابی شروع می شود که مقرون به صرفه ترین مسیر پرواز را انتخاب می کند و از کارمند می خواهد که آن را تأیید کند. در صورتی که کارمند مسیر دیگری را ترجیح دهد، مدیر مستقیم آنها باید آن را تأیید کند. پس از رزرو پرواز، یکی از هتل های از پیش تایید شده باید برای تاریخ های مناسب رزرو شود. اگر هتلی در دسترس نباشد، بلیط هواپیما باید کنسل شود. در این مثال، هیچ نهاد مرکزی برای شروع فرآیند رزرو سفر وجود ندارد. رزرو سفر فرآیندی است و باید به عنوان مدیر فرآیند اجرا شود تصویر سوم در کامنت
#DDD
#domain_driven_design
@code_crafters
سازگاری:
اگرچه الگوی حماسه یک تراکنش چند جزئی را تنظیم می کند، حالات اجزای درگیر در نهایت سازگار است. و اگرچه حماسه در نهایت دستورات مربوطه را اجرا می کند، هیچ دو تراکنشی را نمی توان اتمی در نظر گرفت.
این با یکی دیگر از اصول طراحی کل مرتبط است:
فقط داده‌های درون مرزهای یک تجمیع را میتوان به شدت سازگار در نظر گرفت.
همه چیز بیرون در نهایت سازگار است.
از این به عنوان یک اصل راهنما استفاده کنید تا مطمئن شوید که از حماسه ها برای جبران مرزهای نادرست کل سوء استفاده نمی کنید. عملیات تجاری که باید به یک تجمیع تعلق داشته باشند به داده های کاملاً سازگار نیاز دارند.
الگوی حماسه اغلب با الگوی دیگری اشتباه گرفته می شود: مدیر فرآیند. اگرچه پیاده سازی مشابه است، اما این الگوهای متفاوتی هستند.
مدیر فرآیند:
الگوی حماسه جریان ساده و خطی را مدیریت می کند. به بیان دقیق، یک حماسه رویدادها را با دستورات مربوطه مطابقت می دهد. در مثال‌هایی که برای نشان دادن پیاده‌سازی حماسه استفاده کردیم، در واقع تطبیق ساده رویدادها با دستورات را پیاده‌سازی کردیم:
الگوی مدیر فرآیند، تصویر دوم در کامنت نشان داده شده است، برای اجرای یک فرآیند مبتنی بر منطق تجاری در نظر گرفته شده است. این به عنوان یک واحد پردازش مرکزی تعریف می شود که وضعیت توالی را حفظ می کند و مراحل پردازش بعدی را تعیین می کند.
به عنوان یک قانون ساده، اگر یک حماسه حاوی عبارات if-else برای انتخاب مسیر صحیح عمل باشد، احتمالاً یک مدیر فرآیند است. تفاوت دیگر بین یک مدیر فرآیند و یک حماسه این است که یک حماسه به طور ضمنی با مشاهده یک رویداد خاص، نمونه‌سازی میشود. از طرف دیگر، یک مدیر فرآیند نمی تواند به یک رویداد منبع واحد محدود شود. در عوض، این یک فرآیند تجاری منسجم است که از چند مرحله تشکیل شده است. از این رو، یک مدیر فرآیند باید به صراحت معرفی شود. به مثال زیر توجه کنید:
رزرو یک سفر کاری با الگوریتم مسیریابی شروع می شود که مقرون به صرفه ترین مسیر پرواز را انتخاب می کند و از کارمند می خواهد که آن را تأیید کند. در صورتی که کارمند مسیر دیگری را ترجیح دهد، مدیر مستقیم آنها باید آن را تأیید کند. پس از رزرو پرواز، یکی از هتل های از پیش تایید شده باید برای تاریخ های مناسب رزرو شود. اگر هتلی در دسترس نباشد، بلیط هواپیما باید کنسل شود. در این مثال، هیچ نهاد مرکزی برای شروع فرآیند رزرو سفر وجود ندارد. رزرو سفر فرآیندی است و باید به عنوان مدیر فرآیند اجرا شود تصویر سوم در کامنت
#DDD
#domain_driven_design
@code_crafters
❤6
Job Descriptions.docx
24.7 KB
موقعیت اخذ جاب آفر انگلیس
موقعیتهای شغلی:
مدیر فنی
هوش مصنوعی و یادگیری ماشین
دیتا ساینس
مدیر پروژه
دواپس
امنیت
فول استک
اندروید یا ios
و ui ux
یسری توضیحات بدم
۱-ابتدا یه محاسبه فنی از طرف شرکت ما (راهبران رایان فناکو) جهت تایید توانایی تخصصی خواهید شد
۲-آیلتس با نمره حداقل ۵
۳-صد و ده هزار پوند (این پول به حساب خودتون داخل صرافی بلوکه میشه و بعد از استقرار در شرکت و بستن قرارداد با شرکت ثالث پول به حساب شرکت ثالث انتقال میسه)
۴-حقوق دریافتی ماهیانه ۳۸۰۰ پوند و قرارداد اولیه دو ساله است
۵-اخذ اقامت همراه خوانواده یا پارتنر
جهت اطلاعات بیشتر پیام بدید
@behzad_azadi
@code_crafters
موقعیتهای شغلی:
مدیر فنی
هوش مصنوعی و یادگیری ماشین
دیتا ساینس
مدیر پروژه
دواپس
امنیت
فول استک
اندروید یا ios
و ui ux
یسری توضیحات بدم
۱-ابتدا یه محاسبه فنی از طرف شرکت ما (راهبران رایان فناکو) جهت تایید توانایی تخصصی خواهید شد
۲-آیلتس با نمره حداقل ۵
۳-صد و ده هزار پوند (این پول به حساب خودتون داخل صرافی بلوکه میشه و بعد از استقرار در شرکت و بستن قرارداد با شرکت ثالث پول به حساب شرکت ثالث انتقال میسه)
۴-حقوق دریافتی ماهیانه ۳۸۰۰ پوند و قرارداد اولیه دو ساله است
۵-اخذ اقامت همراه خوانواده یا پارتنر
جهت اطلاعات بیشتر پیام بدید
@behzad_azadi
@code_crafters
❤2
طراحی اکتشافی (heuristic)
در بخش‌های ابتدایی راجب ابزارهای طراحی دامنه محور برای تجزیه و تحلیل حوزه‌های تجاری و تصمیم گیری در مورد طراحی استراتژیک صحبت کردیم. در بخش دیگر درباره الگوی طراحی تاکتیکی، راه‌های مختلف برای پیاده سازی منطق تجاری، سازماندهی معماری سیستم و برقراری ارتباط بین اجزای سیستم حرف زدیم
در ادامه راجب ایجاد پل بین دو بخش طراحی استراتژیک و طراحی تاکتیکی صحبت میکنیم
اکتشافی:
یک قانون سخت و قطعی نیست. در عوض، این یک قانون سرانگشتی است: تضمینی برای کامل بودن نیست، اما برای اهداف فوری کافی است. به عبارت دیگر، استفاده از اکتشافی یک رویکرد حل مسئله موثر است که نویز ذاتی بسیاری از نشانه‌ها را نادیده می‌گیرد و در عوض بر «نیروهای باتلاقی» که در مهم‌ترین نشانه‌ها منعکس شده‌اند تمرکز میکند. حوزه‌های مختلف کسب‌وکار و در اصل مشکلاتی که تصمیم‌های طراحی مختلف به آنها پرداخته‌اند.
بافت‌های محدود:
هم مرزهای گسترده و هم باریک میتوانند با تعریف یک بافت محدود معتبر که یک زبان فراگیر ثابت را در بر می‌گیرد، مناسب باشند. اما با این حال، اندازه بهینه یک بافت محدود چقدر است؟ این سوال به ویژه با توجه به معادله مکرر بافت‌های محدود با میکروسرویس‌ها اهمیت دارد. آیا باید همیشه برای کوچک‌ترین بافت‌های محدود ممکن تلاش کنیم؟
اندازه سرویس یکی از کم کاربردترین هاست
به جای اینکه مدل را تابعی از اندازه دلخواه قرار دهیم که برای بافت‌های محدود کوچک بهینه سازی میشود. انجام برعکس آن بسیار موثرتر است: اندازه بافت محدود را به عنوان تابعی از مدلی که در بر می‌گیرد در نظر بگیرید. تغییرات نرم‌افزاری که بر بافت‌های محدود متعدد تأثیر می‌گذارند، گران هستند و به هماهنگی زیادی نیاز دارند، به‌ویژه اگر بافت‌های محدود تحت تأثیر توسط تیم‌های مختلف پیاده‌سازی شوند. چنین تغییراتی که در یک بافت محدود محصور نشده‌اند، نشانه طراحی بی اثر مرزهای بافت‌ها هستند. متأسفانه، بازسازی مرزهای بافت محدود کاری گران است، و در بسیاری از موارد، مرزهای ناکارآمد بدون مراقبت باقی می مانند و در نهایت بدهی فنی انباشته می شوند
تغییراتی که مرزهای بافت‌های محدود را باطل می کند، معمولاً زمانی رخ می دهد که دامنه کسب و کار به خوبی شناخته نشده باشد یا الزامات کسب و کار به طور مکرر تغییر کند. هم نوسانات و هم عدم قطعیت از ویژگی های هسته هستند. ما می توانیم آن را به عنوان یک هوریستیک برای طراحی مرزهای بافت محدود استفاده کنیم. مرزهای بافت محدود گسترده، یا آنهایی که چندین زیر دامنه را در بر می گیرند، اشتباه کردن در مورد مرزها یا مدل های زیرخ دامنه های گنجانده شده را ایمن تر می کنند. بازسازي مرزهاي منطقي به طور قابل توجهي كمتر از بازسازي مرزهاي فيزيكي است. از این رو، هنگام طراحی زمینه های محدود، با مرزهای گسترده تر شروع کنید. در صورت نیاز، با کسب دانش دامنه، مرزهای گسترده را به مرزهای کوچکتر تجزیه کنید. این اکتشافی عمدتاً برای بافت‌های محدود که زیر دامنه‌های اصلی را در بر می‌گیرد، اعمال میشود، زیرا هم زیردامنه‌های عمومی و هم زیردامنه‌های پشتیبان فرمول‌بندی‌شده‌تر و بسیار کمتر فرار هستند. هنگام ایجاد یک بافت محدود که حاوی یک زیر دامنه اصلی است، می‌توانید از خود در برابر تغییرات پیش‌بینی نشده با اضافه کردن سایر زیر دامنه‌هایی که زیر دامنه اصلی اغلب با آنها تعامل دارد، محافظت کنید.
الگوهای پیاده‌سازی منطق تجاری
چهار روش مختلف برای مدلسازی منطق تجاری را آموختید: اسکریپت تراکنش، رکورد فعال، مدل دامنه، و الگوهای مدل دامنه منبع رویداد. هر دو اسکریپت تراکنش و الگوهای رکورد فعال برای زیر دامنه‌هایی با منطق تجاری ساده مناسب‌تر هستند: برای مثال، پشتیبانی از زیر دامنه‌ها یا ادغام یک راه‌حل شخص ثالث برای یک زیر دامنه عمومی. تفاوت بین این دو الگو در پیچیدگی ساختارهای داده است. الگوی اسکریپت تراکنش می تواند الگوهای پیاده سازی منطق تجاری برای ساختارهای داده ساده استفاده می شود، در حالی که الگوی رکورد فعال به کپسوله کردن نگاشت ساختارهای داده پیچیده به پایگاه داده زیربنایی کمک می کند.
#DDD
#domain_driven_design
@code_crafters
در بخش‌های ابتدایی راجب ابزارهای طراحی دامنه محور برای تجزیه و تحلیل حوزه‌های تجاری و تصمیم گیری در مورد طراحی استراتژیک صحبت کردیم. در بخش دیگر درباره الگوی طراحی تاکتیکی، راه‌های مختلف برای پیاده سازی منطق تجاری، سازماندهی معماری سیستم و برقراری ارتباط بین اجزای سیستم حرف زدیم
در ادامه راجب ایجاد پل بین دو بخش طراحی استراتژیک و طراحی تاکتیکی صحبت میکنیم
اکتشافی:
یک قانون سخت و قطعی نیست. در عوض، این یک قانون سرانگشتی است: تضمینی برای کامل بودن نیست، اما برای اهداف فوری کافی است. به عبارت دیگر، استفاده از اکتشافی یک رویکرد حل مسئله موثر است که نویز ذاتی بسیاری از نشانه‌ها را نادیده می‌گیرد و در عوض بر «نیروهای باتلاقی» که در مهم‌ترین نشانه‌ها منعکس شده‌اند تمرکز میکند. حوزه‌های مختلف کسب‌وکار و در اصل مشکلاتی که تصمیم‌های طراحی مختلف به آنها پرداخته‌اند.
بافت‌های محدود:
هم مرزهای گسترده و هم باریک میتوانند با تعریف یک بافت محدود معتبر که یک زبان فراگیر ثابت را در بر می‌گیرد، مناسب باشند. اما با این حال، اندازه بهینه یک بافت محدود چقدر است؟ این سوال به ویژه با توجه به معادله مکرر بافت‌های محدود با میکروسرویس‌ها اهمیت دارد. آیا باید همیشه برای کوچک‌ترین بافت‌های محدود ممکن تلاش کنیم؟
اکتشافی مفید و آشکار بسیاری برای تعیین مرزهای یک سرویس وجود دارد
اندازه سرویس یکی از کم کاربردترین هاست
به جای اینکه مدل را تابعی از اندازه دلخواه قرار دهیم که برای بافت‌های محدود کوچک بهینه سازی میشود. انجام برعکس آن بسیار موثرتر است: اندازه بافت محدود را به عنوان تابعی از مدلی که در بر می‌گیرد در نظر بگیرید. تغییرات نرم‌افزاری که بر بافت‌های محدود متعدد تأثیر می‌گذارند، گران هستند و به هماهنگی زیادی نیاز دارند، به‌ویژه اگر بافت‌های محدود تحت تأثیر توسط تیم‌های مختلف پیاده‌سازی شوند. چنین تغییراتی که در یک بافت محدود محصور نشده‌اند، نشانه طراحی بی اثر مرزهای بافت‌ها هستند. متأسفانه، بازسازی مرزهای بافت محدود کاری گران است، و در بسیاری از موارد، مرزهای ناکارآمد بدون مراقبت باقی می مانند و در نهایت بدهی فنی انباشته می شوند
تغییراتی که مرزهای بافت‌های محدود را باطل می کند، معمولاً زمانی رخ می دهد که دامنه کسب و کار به خوبی شناخته نشده باشد یا الزامات کسب و کار به طور مکرر تغییر کند. هم نوسانات و هم عدم قطعیت از ویژگی های هسته هستند. ما می توانیم آن را به عنوان یک هوریستیک برای طراحی مرزهای بافت محدود استفاده کنیم. مرزهای بافت محدود گسترده، یا آنهایی که چندین زیر دامنه را در بر می گیرند، اشتباه کردن در مورد مرزها یا مدل های زیرخ دامنه های گنجانده شده را ایمن تر می کنند. بازسازي مرزهاي منطقي به طور قابل توجهي كمتر از بازسازي مرزهاي فيزيكي است. از این رو، هنگام طراحی زمینه های محدود، با مرزهای گسترده تر شروع کنید. در صورت نیاز، با کسب دانش دامنه، مرزهای گسترده را به مرزهای کوچکتر تجزیه کنید. این اکتشافی عمدتاً برای بافت‌های محدود که زیر دامنه‌های اصلی را در بر می‌گیرد، اعمال میشود، زیرا هم زیردامنه‌های عمومی و هم زیردامنه‌های پشتیبان فرمول‌بندی‌شده‌تر و بسیار کمتر فرار هستند. هنگام ایجاد یک بافت محدود که حاوی یک زیر دامنه اصلی است، می‌توانید از خود در برابر تغییرات پیش‌بینی نشده با اضافه کردن سایر زیر دامنه‌هایی که زیر دامنه اصلی اغلب با آنها تعامل دارد، محافظت کنید.
الگوهای پیاده‌سازی منطق تجاری
چهار روش مختلف برای مدلسازی منطق تجاری را آموختید: اسکریپت تراکنش، رکورد فعال، مدل دامنه، و الگوهای مدل دامنه منبع رویداد. هر دو اسکریپت تراکنش و الگوهای رکورد فعال برای زیر دامنه‌هایی با منطق تجاری ساده مناسب‌تر هستند: برای مثال، پشتیبانی از زیر دامنه‌ها یا ادغام یک راه‌حل شخص ثالث برای یک زیر دامنه عمومی. تفاوت بین این دو الگو در پیچیدگی ساختارهای داده است. الگوی اسکریپت تراکنش می تواند الگوهای پیاده سازی منطق تجاری برای ساختارهای داده ساده استفاده می شود، در حالی که الگوی رکورد فعال به کپسوله کردن نگاشت ساختارهای داده پیچیده به پایگاه داده زیربنایی کمک می کند.
#DDD
#domain_driven_design
@code_crafters
❤2👍2
مدل دامنه و نوع آن
مدل دامنه منبع رویداد، خود را به زیر دامنه‌هایی که منطق تجاری پیچیده‌ای دارند، اختصاص می‌دهند: زیر دامنه‌های اصلی. زیر دامنه های اصلی که با تراکنش های پولی سروکار دارند، طبق قانون موظف به ارائه گزارش حسابرسی هستند یا نیاز به تجزیه و تحلیل عمیق از رفتار سیستم دارند، با مدل دامنه منبع رویداد بهتر مورد توجه قرار می گیرند.
با در نظر گرفتن همه اینها، یک اکتشافی موثر برای انتخاب الگوی پیاده سازی منطق تجاری مناسب، پرسیدن سؤالات زیر است:
از آنجایی که یک رابطه قوی بین پیچیدگی یک زیر دامنه و نوع آن وجود دارد، می‌توانیم اکتشافات را با استفاده از درخت تصمیم مبتنی بر دامنه تجسم کنیم تصویر اول در کامنت
ما می توانیم از یک اکتشافی دیگر برای تعریف تفاوت بین منطق تجاری پیچیده و ساده استفاده کنیم. مرز بین این دو نوع منطق تجاری خیلی واضح نیست، اما مفید است. به طور کلی، منطق پیچیده کسب و کار شامل قوانین پیچیده تجاری، یک رویکرد ساده عمدتاً حول اعتبارسنجی ورودی‌ها می‌چرخد. اکتشافی دیگر برای ارزیابی پیچیدگی مربوط به پیچیدگی خود زبان فراگیر است. آیا عمدتاً عملیات CRUD را توصیف می کند یا فرآیندها و قوانین تجاری پیچیده تری را توصیف می کند؟ تصمیم گیری در مورد الگوی پیاده سازی منطق کسب و کار با توجه به پیچیدگی منطق کسب و کار و ساختارهای داده آن راهی برای تایید مفروضات شما در مورد نوع زیر دامنه است. فرض کنید آن را یک زیردامنه اصلی در نظر می گیرید، اما بهترین الگو، اسکریپت رکورد یا تراکنش فعال است. یا فرض کنید آنچه شما فکر می کنید یک زیردامنه پشتیبان است به یک مدل دامنه یا یک مدل دامنه منبع رویداد نیاز دارد. در این مورد، فرصتی عالی برای بازبینی مفروضات خود در مورد حوزه فرعی و به طور کلی دامنه تجاری است. به یاد داشته باشید، مزیت رقابتی یک زیردامنه اصلی لزوماً فنی نیست.
الگوهای معماری:
با سه الگوی معماری آشنا شدید: معماری لایه ای، پورت ها و آداپتورها و CQRS
دانستن الگوی پیاده سازی منطق تجاری مورد نظر، انتخاب یک الگوی معماری را آسان می کند:
تنها استثناء اکتشافی قبلی، الگوی CQRS است. CQRS می تواند نه تنها برای مدل دامنه منبع رویداد، بلکه برای هر الگوی دیگری مفید باشد، اگر زیر دامنه نیاز به نمایش داده های خود در چندین مدل پایدار داشته باشد. تصویر دوم در کامنت یک درخت تصمیم برای انتخاب یک الگوی معماری بر اساس این اکتشافات را نشان می دهد.
استراتژی تست:
دانش الگوی پیاده سازی منطق تجاری و الگوی معماری را می توان به عنوان یک روش اکتشافی برای انتخاب یک استراتژی تست برای پایه کد مورد استفاده قرار داد. به سه استراتژی تست نشان داده شده در تصویر سوم در کامنت نگاهی بیندازید
#DDD
#domain_driven_design
@code_crafters
مدل دامنه منبع رویداد، خود را به زیر دامنه‌هایی که منطق تجاری پیچیده‌ای دارند، اختصاص می‌دهند: زیر دامنه‌های اصلی. زیر دامنه های اصلی که با تراکنش های پولی سروکار دارند، طبق قانون موظف به ارائه گزارش حسابرسی هستند یا نیاز به تجزیه و تحلیل عمیق از رفتار سیستم دارند، با مدل دامنه منبع رویداد بهتر مورد توجه قرار می گیرند.
با در نظر گرفتن همه اینها، یک اکتشافی موثر برای انتخاب الگوی پیاده سازی منطق تجاری مناسب، پرسیدن سؤالات زیر است:
• آیا زیردامنه پول یا سایر تراکنش های پولی را ردیابی می کند یا باید یک گزارش حسابرسی ثابت ارائه کند، یا تجزیه و تحلیل عمیق رفتار آن مورد نیاز کسب و کار است؟ اگر چنین است، از مدل دامنه منبع رویداد استفاده کنید. در غیر این صورت...
• آیا منطق تجاری ساب دامنه پیچیده است؟ اگر چنین است، یک مدل دامنه پیاده سازی کنید.
در غیر این صورت...
• آیا زیر دامنه شامل ساختارهای داده پیچیده است؟ اگر چنین است، از الگوی رکورد فعال استفاده کنید. در غیر این صورت...
• یک اسکریپت تراکنش را پیاده سازی کنید.
از آنجایی که یک رابطه قوی بین پیچیدگی یک زیر دامنه و نوع آن وجود دارد، می‌توانیم اکتشافات را با استفاده از درخت تصمیم مبتنی بر دامنه تجسم کنیم تصویر اول در کامنت
ما می توانیم از یک اکتشافی دیگر برای تعریف تفاوت بین منطق تجاری پیچیده و ساده استفاده کنیم. مرز بین این دو نوع منطق تجاری خیلی واضح نیست، اما مفید است. به طور کلی، منطق پیچیده کسب و کار شامل قوانین پیچیده تجاری، یک رویکرد ساده عمدتاً حول اعتبارسنجی ورودی‌ها می‌چرخد. اکتشافی دیگر برای ارزیابی پیچیدگی مربوط به پیچیدگی خود زبان فراگیر است. آیا عمدتاً عملیات CRUD را توصیف می کند یا فرآیندها و قوانین تجاری پیچیده تری را توصیف می کند؟ تصمیم گیری در مورد الگوی پیاده سازی منطق کسب و کار با توجه به پیچیدگی منطق کسب و کار و ساختارهای داده آن راهی برای تایید مفروضات شما در مورد نوع زیر دامنه است. فرض کنید آن را یک زیردامنه اصلی در نظر می گیرید، اما بهترین الگو، اسکریپت رکورد یا تراکنش فعال است. یا فرض کنید آنچه شما فکر می کنید یک زیردامنه پشتیبان است به یک مدل دامنه یا یک مدل دامنه منبع رویداد نیاز دارد. در این مورد، فرصتی عالی برای بازبینی مفروضات خود در مورد حوزه فرعی و به طور کلی دامنه تجاری است. به یاد داشته باشید، مزیت رقابتی یک زیردامنه اصلی لزوماً فنی نیست.
الگوهای معماری:
با سه الگوی معماری آشنا شدید: معماری لایه ای، پورت ها و آداپتورها و CQRS
دانستن الگوی پیاده سازی منطق تجاری مورد نظر، انتخاب یک الگوی معماری را آسان می کند:
• مدل دامنه منبع رویداد به CQRS نیاز دارد. در غیر این صورت، سیستم در گزینه‌های جستجوی داده‌های خود بسیار محدود خواهد بود و تنها با شناسه خود یک نمونه را واکشی میکند
• مدل دامنه به معماری پورت ها و آداپتورها نیاز دارد. در غیر این صورت، معماری لایه‌ای باعث میشود که تجمیع‌ها و ارزش‌گذاری اشیاء از ماندگاری نادیده گرفته شوند
• الگوی رکورد فعال به بهترین وجه با یک معماری لایه ای همراه با لایه کاربردی (سرویس) اضافی همراه است. این برای منطق کنترل رکوردهای فعال است
• الگوی اسکریپت تراکنش را می توان با معماری لایه ای حداقلی که تنها از سه لایه تشکیل شده است، پیاده سازی کرد.
تنها استثناء اکتشافی قبلی، الگوی CQRS است. CQRS می تواند نه تنها برای مدل دامنه منبع رویداد، بلکه برای هر الگوی دیگری مفید باشد، اگر زیر دامنه نیاز به نمایش داده های خود در چندین مدل پایدار داشته باشد. تصویر دوم در کامنت یک درخت تصمیم برای انتخاب یک الگوی معماری بر اساس این اکتشافات را نشان می دهد.
استراتژی تست:
دانش الگوی پیاده سازی منطق تجاری و الگوی معماری را می توان به عنوان یک روش اکتشافی برای انتخاب یک استراتژی تست برای پایه کد مورد استفاده قرار داد. به سه استراتژی تست نشان داده شده در تصویر سوم در کامنت نگاهی بیندازید
#DDD
#domain_driven_design
@code_crafters
❤2
تفاوت بین استراتژی‌های تست تاکید آنها بر انواع مختلف آزمون‌ها است: واحد، ادغام و پایان رو به انتها.
بیایید هر استراتژی و زمینه ای که هر الگو باید در آن استفاده شود را تحلیل کنیم.
هرم تست:
هرم تست کلاسیک بر تست های واحد، تست های ادغام کمتر و حتی تست های سرتاسر کمتر تاکید دارد. هر دو نوع الگوهای مدل دامنه به بهترین وجه با هرم آزمایشی مورد بررسی قرار می گیرند. انباشته ها و اشیاء ارزش واحدهای عالی برای آزمایش موثر منطق تجاری هستند.
تست الماس:
الماس آزمایشی بیشترین تمرکز را بر روی تست های یکپارچه سازی دارد. هنگامی که الگوی رکورد فعال استفاده می شود، منطق تجاری سیستم، طبق تعریف، در هر دو لایه منطق تجاری و خدماتی پخش می شود. بنابراین، برای تمرکز بر ادغام دو لایه، هرم آزمایشی انتخاب موثرتری است.
هرم تست معکوس:
هرم تست معکوس بیشترین توجه را به تست های انتها به انتها می دهد: بررسی گردش کار برنامه از ابتدا تا انتها. چنین رویکردی به بهترین وجه با پایگاه‌های کدی که الگوی اسکریپت تراکنش را پیاده‌سازی میکنند مناسب است: منطق تجاری ساده است و تعداد لایه‌ها حداقل است، که تأیید جریان سرتاسر سیستم را مؤثرتر میکند. تصویر اول در کامنت درخت تصمیم گیری استراتژی تست را نشان می دهد.
درخت تصمیم طراحی تاکتیکی الگوهای منطق کسب و کار، الگوهای معماری، و اکتشافات استراتژی تست را می توان با یک درخت تصمیم طراحی تاکتیکی، همانطور که در تصویر دوم در کامنت نشان داده شده است، متحد و خلاصه کرد. درخت تصمیم طراحی تاکتیکی همانطور که می بینید، شناسایی انواع زیر دامنه ها و پیروی از درخت تصمیم، نقطه شروع محکمی برای تصمیم گیری های طراحی ضروری به شما می دهد. با این حال، تکرار این نکته مهم است که اینها اکتشافی هستند، نه قوانین سخت. برای هر قاعده استثنایی وجود دارد، چه رسد به اکتشافی، که بنا به تعریف در صد درصد موارد صحیح نیست.
#DDD
#domain_driven_design
@code_crafters
بیایید هر استراتژی و زمینه ای که هر الگو باید در آن استفاده شود را تحلیل کنیم.
هرم تست:
هرم تست کلاسیک بر تست های واحد، تست های ادغام کمتر و حتی تست های سرتاسر کمتر تاکید دارد. هر دو نوع الگوهای مدل دامنه به بهترین وجه با هرم آزمایشی مورد بررسی قرار می گیرند. انباشته ها و اشیاء ارزش واحدهای عالی برای آزمایش موثر منطق تجاری هستند.
تست الماس:
الماس آزمایشی بیشترین تمرکز را بر روی تست های یکپارچه سازی دارد. هنگامی که الگوی رکورد فعال استفاده می شود، منطق تجاری سیستم، طبق تعریف، در هر دو لایه منطق تجاری و خدماتی پخش می شود. بنابراین، برای تمرکز بر ادغام دو لایه، هرم آزمایشی انتخاب موثرتری است.
هرم تست معکوس:
هرم تست معکوس بیشترین توجه را به تست های انتها به انتها می دهد: بررسی گردش کار برنامه از ابتدا تا انتها. چنین رویکردی به بهترین وجه با پایگاه‌های کدی که الگوی اسکریپت تراکنش را پیاده‌سازی میکنند مناسب است: منطق تجاری ساده است و تعداد لایه‌ها حداقل است، که تأیید جریان سرتاسر سیستم را مؤثرتر میکند. تصویر اول در کامنت درخت تصمیم گیری استراتژی تست را نشان می دهد.
درخت تصمیم طراحی تاکتیکی الگوهای منطق کسب و کار، الگوهای معماری، و اکتشافات استراتژی تست را می توان با یک درخت تصمیم طراحی تاکتیکی، همانطور که در تصویر دوم در کامنت نشان داده شده است، متحد و خلاصه کرد. درخت تصمیم طراحی تاکتیکی همانطور که می بینید، شناسایی انواع زیر دامنه ها و پیروی از درخت تصمیم، نقطه شروع محکمی برای تصمیم گیری های طراحی ضروری به شما می دهد. با این حال، تکرار این نکته مهم است که اینها اکتشافی هستند، نه قوانین سخت. برای هر قاعده استثنایی وجود دارد، چه رسد به اکتشافی، که بنا به تعریف در صد درصد موارد صحیح نیست.
#DDD
#domain_driven_design
@code_crafters
❤3👍2