مصالح یکی از مفاهیمی است که در طراحی دامنه محور اشتباه گرفته شده است.
انباشته چیست؟ مطمئناً، این یک الگوی مرکزی برای طراحی دامنه محور است… اما آیا فقط مجموعه ای از اشیاء است؟
مارتین فاولر توضیح می دهد:
انباشته‌ها عنصر اصلی انتقال داده‌های ذخیره‌سازی هستند – شما درخواست می‌کنید تا کل مجموعه‌ها را بارگیری یا ذخیره کنید. معاملات نباید از مرزهای کل عبور کنند.
https://www.martinfowler.com/bliki/DDD_Aggregate.html
کسانی که در DDD تجربه دارند ممکن است بفهمند که این به چه معناست و چرا کاربرد دارد.
اما برای کسانی که شروع به آشنایی با مصالح میکنند، چنین توضیحی ممکن است بسیار دقیق و ظریف باشد.
بیایید شروع کنیم به اینکه چه ترکیبی است نیست.
آنچه که یک مجموع نیست
جمع این نیست:
- فقط یک نمودار از موجودیت ها
- صرفاً یک شیء غنی از رفتار
- موجودیت یا مجموعه ای از موجودیت ها که می توانید آنها را در جداول پایگاه داده خود ریخته باشید
خب… چیه؟
این معمولاً جایی است که مردم شروع به صحبت در مورد مرزهای سازگاری، ثبات معاملاتی، ثبات نهایی، مرزهای کل، متغیرها، ریشه های کل و غیره می کنند.
هنگامی که در مورد این چیزها یاد می گیریم، طبیعی است که به یک اصطلاح یا ایده آشنا بپردازیم، وقتی این همه اصطلاحات مخصوص به ما پرتاب می شود. از آنجا، ما (به اشتباه) ایده ای درباره این موضوع ایجاد می کنیم.
بیایید سعی کنیم موارد را ساده و کاربردی نگه داریم.
حباب ها
من دوست دارم از یک ایده بسیار ساده استفاده کنم تا به مردم کمک کنم جوهره چیستی مصالح را درک کنند.
حباب ها.
تصور کنید پروژه نرم افزاری شما یک پایگاه کد عظیم نیست – بلکه مجموعه ای از حباب های کوچک است. هر حباب را می توان به طور مستقل کار کرد. این بدان معناست که شما فقط باید به آنچه در هر لحظه در حباب است فکر کنید – نه کل سیستم یکباره.
سنگدانه ها یکسان هستند. آنها حباب هستند. فقط در مقیاس کوچکتر.
مورد استفاده: تیم ها
تصور کنید ما در حال ساخت یک ویژگی جدید برای سیستم خود هستیم. این ویژگی جدید شامل مفهوم پروژه ها، تیم ها و اعضای تیم است.
هر تیم می تواند چندین کارمند مرتبط با خود داشته باشد.
اعضای کارکنان می توانند بخشی از چندین تیم باشند.
هر تیم می تواند چندین پروژه داشته باشد.
خوب، به اندازه کافی ساده است.
بیایید فیلدهایی را که ممکن است روی هر شی وجود داشته باشد اضافه کنیم:
پایگاه داده همه چیزها
آیا این فقط شبیه یک نمودار موجودیت نیست؟ آیا جداول پایگاه داده سر شما فریاد نمی زنند؟
“بدیهی است” ما باید یک جدول ترکیبی داشته باشیم که هر تیم را با هر یک از اعضای تیم پیوند دهد.
فقط صبر کن
بیایید به جای آن به رفتار فکر کنیم و با اینها به عنوان اشیاء کد رفتار نکنیم. بیایید با آنها به عنوان موضوعات یا مفاهیم تجاری رفتار کنیم. این اشیا چه کاری می توانند انجام دهند؟
خب معلوم نیست؟ تو می توانی ايجاد كردن یک تیم. ویرایش کنید یک تیم. حذف یک تیم.
بدیهی است که حذف یک تیم به این معنی است که تمام پروژه‌های مرتبط باید آبشار شوند و همچنین حذف شوند.
نکته: این را که اینها رفتارهای واقعی سیستم ما نیست را کنار بگذاریم. هر زمان که زبان CRUDy را می بینید، باید یک پرچم قرمز باشد!
تجارت واقعی چندان ساده نیست
اما صبر کن شما به تازگی از کاربران خود متوجه شدید که این کار نمی کند. فرضیاتی که در مورد کسب و کار کردید اشتباه بود…
آنجا هستند زمان هایی که پروژه ها از یک تیم به تیم دیگر منتقل می شوند.
آنجا هستند زمان هایی که پروژه ها برای مدتی یتیم می شوند.
بنابراین اکنون سؤالات دیگری مطرح می شود:
- مدل ما الان باید چه شکلی باشه؟
- وقتی کد خود را می نویسیم، آیا باید کل نمودار اشیاء را در حافظه بارگذاری کنیم؟
- وقتی یک پروژه یتیم می شود چه اتفاقی می افتد؟ آیا تیم ها فقط به یک شیء پروژه پوچ ارجاع خواهند داد؟
الزامات بیشتری که کارها را پیچیده می کند
اکنون کسب و کار یک نیاز جدید دارد: نقش یک عضو تیم می تواند در هر پروژه تغییر کند.
بنابراین … آیا ما فقط یک جدول ترکیبی دیگر ایجاد می کنیم تا هر یک از اعضای تیم را با هر پروژه ای که در آن هستند و نقش هر پروژه مطابقت دهیم؟
این کاری است که ما معمولا انجام می دهیم. توسعه دهندگان به طور طبیعی ابتدا به سیستم ها از نظر طراحی پایگاه داده فکر می کنند 🤦♂️ .
توجه: بله، این مشکل بزرگی است که طراحی دامنه محور سعی در جلوگیری از آن دارد!
با هر نیاز جدید، مدل ما بیشتر پف می کند. با گذشت زمان، این ممکن است حافظه زیادی را در سیستم ما نیز مصرف کند.
پروژه ای را تصور کنید که تیم آن 500 عضو دارد. بله، اینها پروژه های بزرگی هستند که ما در مورد آنها صحبت می کنیم.
ما باید همه اعضای کارکنان را در حافظه بارگذاری کنیم، و تمام اطلاعات آنها را نیز!
که منجر به مشکلات عملکرد در مورد استفاده از حافظه و غیره می شود. آیا راه بهتری وجود دارد؟
مصالح
سنگدانه ها هستند که این نوع مشکلات را حل می کنند.
آنها کمک میکنند:
- وقتی مدل‌هایمان از کنترل خارج شدند، ساده‌سازی کنیم
- قوانین پیچیده کسب و کار را جدا کنید
- هنگام بارگذاری نمودارهای شی بزرگ در حافظه، با مشکلات عملکردی مقابله کنید
- به انعطاف پذیری اجازه دهید تا به راحتی با الزامات تجاری غیرمنتظره آینده مقابله کنید
این همان چیزی است که تجمیع می کند هستند برای.
خوب. ولی آنها چه هستند؟
به جای اینکه به شما بگویم، به شما نشان خواهم داد که در این مورد چه شکلی به نظر می رسد (در غیر این صورت، باید در مورد سازگاری، مرزهای معاملاتی، همزمانی و غیره صحبت کنیم!).
توجه داشته باشید که من مدل اصلی Member را به سه قسمت تقسیم کردم؟
تیم و پروژه «نسخه» یا «نما» اختصاصی خود را از عضو دارند که فقط داده‌های دقیق مورد نیاز برای تصمیم‌گیری در مورد قوانین و رفتارهای تجاری در «حباب» خود را دارد.
به عنوان مثال، نقش عضو مورد نیاز حباب تیم نیست. چرا وقتی به آن تعلق ندارد آن را آنجا نگه دارید؟
در عوض، ما مدل خود را به دو “شاخه” تقسیم کرده ایم. در این مورد، دو حباب/مجموعه.
برای اینکه بتوانیم یک عضو را به چندین تیم اختصاص دهیم، سپس باید یک مدل معتبر اختصاصی از یک عضو تیم ایجاد کنیم و موجودیت عضو مجموع دیگر را به عنوان یک مرجع کلید خارجی مرتبط کنیم. (باز هم، ما در مورد پایگاه های داده صحبت نمی کنیم).
توجه: توجه داشته باشید که من شناسه‌های خاصی را به مدل‌های غیرمعتبر «عضو» اضافه کردم (مانند «TeamMemberId»)
خیلی چیزهای بیشتری برای بحث وجود دارد. و بسیاری از پیشرفت‌های دیگر که می‌توانیم در مورد استفاده از اشیاء ارزش و غیره در این مدل ایجاد کنیم.
من فکر می‌کنم این برای کمک به شما کافی است تا متوجه شوید که مجموع‌ها چیزی بیش از ایجاد یک نمودار از موجودیت‌ها هستند.
همه چیز در مورد اجازه دادن به قوانین دامنه برای راهنمایی شما است.
خیلی اوقات، انباشته هایی که کشف می کنیم، آن دسته از موادی نیستند که فکر می کردیم به آن نیاز داریم!
