نکات کلیدی
۱. نرم‌افزار ریشه‌ای عمیق در حوزه‌ی خود دارد
یک بسته‌ی نرم‌افزاری مفید را نمی‌توان از آن حوزه‌ی واقعیت که قرار است به مدیریت آن کمک کند، جدا کرد.
حوزه را به‌خوبی بشناسید. نرم‌افزار برای حل مسائل دنیای واقعی یا خودکارسازی فرآیندهای کسب‌وکار وجود دارد. این نرم‌افزار به‌طور بنیادین به حوزه‌ی خاصی از واقعیت که خدمت می‌کند، متصل است. بدون درک عمیق از این حوزه، نرم‌افزار نمی‌تواند به‌طور مؤثر آن را بهبود بخشد و ممکن است باعث اختلال یا هرج‌ومرج شود.
متخصصان حوزه کلید اصلی‌اند. افرادی که واقعاً حوزه را می‌شناسند، متخصصانی هستند که در آن حوزه فعالیت می‌کنند، نه لزوماً توسعه‌دهندگان یا تحلیل‌گران نرم‌افزار. همکاری نزدیک با این متخصصان برای استخراج دانش لازم ضروری است. این دانش خام باید سپس به صورت مدل انتزاعی و سازمان‌یافته درآید.
نرم‌افزار بازتاب‌دهنده‌ی حوزه است. نرم‌افزار خوب باید مفاهیم اصلی، عناصر و روابط حوزه‌ی خود را در بر گیرد. خود کد باید این درک را منعکس کند تا فردی که با حوزه آشناست بتواند با خواندن کد به بینش برسد. نرم‌افزاری که ریشه‌ی عمیقی در حوزه ندارد، در تطبیق با تغییرات زمان دچار مشکل خواهد شد.
۲. زبان فراگیر را با متخصصان حوزه بسازید
از مدل به‌عنوان ستون فقرات یک زبان استفاده کنید.
شکاف ارتباطی را پر کنید. توسعه‌دهندگان و متخصصان حوزه اغلب زبان‌های متفاوتی دارند که منجر به سوءتفاهم و شکست پروژه می‌شود. توسعه‌دهندگان به مفاهیم کد فکر می‌کنند، در حالی که متخصصان از اصطلاحات خاص حوزه خود استفاده می‌کنند. زبان مشترک برای همکاری مؤثر حیاتی است.
زبان مبتنی بر مدل. راه‌حل ایجاد زبانی مشترک است که مستقیماً بر اساس مدل حوزه ساخته شده باشد. این «زبان فراگیر» باید توسط همه اعضای تیم در تمام اشکال ارتباطی، از جمله گفتار، نوشتار و نمودارها، به‌طور مداوم استفاده شود تا وضوح و دقت را تضمین کند.
زبان مدل را شکل می‌دهد. فرایند ایجاد و پالایش زبان فراگیر تکراری است. با بحث و روشن‌سازی اصطلاحات توسط تیم، مدل نیز تکامل می‌یابد. متخصصان حوزه اصطلاحات نامناسب را به چالش می‌کشند و توسعه‌دهندگان ابهامات را شناسایی می‌کنند که منجر به مدلی قوی‌تر و دقیق‌تر می‌شود که همه آن را درک می‌کنند.
۳. طراحی نرم‌افزار را مستقیماً از مدل حوزه انجام دهید
اگر طراحی یا بخشی مرکزی از آن به مدل حوزه نگاشت نداشته باشد، آن مدل ارزش کمی دارد و صحت نرم‌افزار مشکوک است.
از جدایی تحلیل و طراحی پرهیز کنید. معمولاً مدل‌های تحلیلی جدا از طراحی کد و توسط افراد مختلف ساخته می‌شوند. این امر منجر به مدل‌هایی می‌شود که از نظر تحلیلی درست‌اند اما در عمل قابل پیاده‌سازی نیستند و توسعه‌دهندگان از آن‌ها فاصله می‌گیرند و مدل بی‌ربط می‌شود. بین مراحل دیدگاه‌ها منتقل نمی‌شود.
پیاده‌سازی مبتنی بر مدل. مدل باید با در نظر گرفتن پیاده‌سازی نرم‌افزار ساخته شود و توسعه‌دهندگان از ابتدا در آن دخیل باشند. طراحی کد باید به‌طور واضح مدل حوزه را منعکس کند. این اتصال نزدیک باعث می‌شود مدل مرتبط باقی بماند و کد مفاهیم حوزه را به‌درستی بیان کند.
کد بیان مدل است. تغییرات در کد باید به‌عنوان تغییرات در مدل دیده شود و نیازمند دقت باشد. زبان‌های برنامه‌نویسی شیءگرا برای این رویکرد مناسب‌اند زیرا ساختارهایی مانند کلاس‌ها و ارتباطات را ارائه می‌دهند که مستقیماً به عناصر مدل نگاشت می‌شوند. این امر کد را خواناتر و قابل نگهداری‌تر می‌کند.
۴. برنامه‌ها را با لایه‌های مشخص ساختاربندی کنید
تمام کد مرتبط با مدل حوزه را در یک لایه متمرکز کنید و آن را از کد رابط کاربری، برنامه و زیرساخت جدا نمایید.
جدا کردن دغدغه‌ها. در برنامه‌های پیچیده، منطق حوزه اغلب با کد رابط کاربری، پایگاه داده و سایر کدهای فنی درهم می‌آمیزد. این درهم‌تنیدگی فهم، تغییر و تست منطق حوزه را دشوار می‌کند. تغییرات فنی سطحی ممکن است به‌طور ناخواسته قوانین کسب‌وکار را بشکند.
تقسیم‌بندی به لایه‌ها. الگوی معماری استاندارد تقسیم برنامه به لایه‌های متمایز است که هر کدام فقط به لایه‌های پایین‌تر وابسته‌اند. این کار باعث کاهش وابستگی و جداسازی دغدغه‌ها می‌شود. ساختار معمول شامل:
- رابط کاربری (ارائه): مدیریت تعامل با کاربر.
- لایه برنامه: هماهنگی وظایف و نگهداری وضعیت وظایف (بدون منطق کسب‌وکار).
- لایه حوزه: شامل منطق اصلی کسب‌وکار و وضعیت اشیاء.
- لایه زیرساخت: پشتیبانی فنی مانند ذخیره‌سازی و پیام‌رسانی.
تمرکز بر لایه حوزه. با جدا کردن لایه حوزه، اشیاء آن می‌توانند صرفاً بر بیان مدل حوزه و رفتار آن تمرکز کنند. آن‌ها از مسئولیت‌هایی مانند نمایش خود یا مدیریت دسترسی به پایگاه داده آزاد می‌شوند. این امکان را می‌دهد که مدل حوزه غنی و روشن باشد و دانش کسب‌وکار اساسی را به‌خوبی ثبت کند.
۵. اشیاء اصلی حوزه را تمییز دهید: موجودیت‌ها و اشیاء ارزش
وقتی یک شیء به‌واسطه هویت خود متمایز می‌شود نه ویژگی‌هایش، این نکته را در تعریف مدل برجسته کنید.
هویت برای موجودیت‌ها اهمیت دارد. برخی اشیاء حوزه هویت پیوسته‌ای دارند که در طول چرخه عمرشان حفظ می‌شود، صرف‌نظر از ویژگی‌هایشان. این‌ها موجودیت‌ها هستند. مثلاً مشتری (با شناسه مشتری) یا حساب بانکی (با شماره حساب). یکتایی آن‌ها اهمیت بالایی دارد.
ویژگی‌ها برای اشیاء ارزش مهم‌اند. اشیاء حوزه دیگر فقط با ویژگی‌هایشان تعریف می‌شوند و هویت مفهومی ندارند؛ اگر ویژگی‌هایشان یکسان باشد، قابل تعویض‌اند. این‌ها اشیاء ارزش‌اند. مثلاً نقطه (با مختصات) یا آدرس (با خیابان، شهر، استان).
طراحی را با اشیاء ارزش ساده کنید. هر شیء نیازی به هویت ندارد. تبدیل اشیاء به اشیاء ارزش طراحی را ساده می‌کند و پیچیدگی ردیابی هویت را حذف می‌کند. اشیاء ارزش باید ترجیحاً تغییرناپذیر باشند؛ پس از ایجاد، ویژگی‌هایشان تغییر نمی‌کند. این امکان اشتراک یا کپی آزادانه بدون خطر مشکلات یکپارچگی داده را فراهم می‌کند.
۶. رفتار حوزه را با سرویس‌ها و ماژول‌ها تعریف کنید
وقتی رفتاری در حوزه شناسایی می‌شود، بهترین کار اعلام آن به‌عنوان سرویس است.
رفتاری که در اشیاء نمی‌گنجد. همه منطق حوزه به‌طور طبیعی به موجودیت یا شیء ارزش تعلق ندارد. برخی عملیات نمایانگر فرآیندها یا تبدیل‌های مهمی هستند که چندین شیء را دربرمی‌گیرند. قرار دادن چنین رفتاری در یک شیء، مسئولیت اصلی آن را نقض و وابستگی نامطلوب ایجاد می‌کند.
سرویس‌ها را معرفی کنید. برای رفتاری که به‌خوبی در وضعیت یا هویت شیء نمی‌گنجد، آن را به‌عنوان سرویس تعریف کنید. سرویس‌ها عملیات بدون حالت هستند که روی اشیاء حوزه عمل می‌کنند یا آن‌ها را هماهنگ می‌سازند. آن‌ها مفاهیم مهم حوزه را که در زبان فراگیر به صورت فعل هستند، در بر می‌گیرند.
با ماژول‌ها سازماندهی کنید. با رشد مدل حوزه، مدیریت آن پیچیده می‌شود. ماژول‌ها برای سازماندهی مفاهیم و وظایف مرتبط به کار می‌روند و پیچیدگی را کاهش می‌دهند. آن‌ها مجموعه‌های همبسته‌ای از کلاس‌ها و روابط را گروه‌بندی می‌کنند و خوانایی و نگهداری مدل را با کاهش وابستگی‌ها بهبود می‌بخشند.
۷. چرخه عمر اشیاء را با مجموعه‌ها، کارخانه‌ها و مخازن مدیریت کنید
تضمین سازگاری تغییرات اشیاء در مدلی با ارتباطات پیچیده دشوار است.
حفظ یکپارچگی داده‌ها. مدل‌های حوزه اغلب شامل شبکه‌های پیچیده‌ای از اشیاء مرتبط‌اند. تضمین سازگاری داده و اعمال قواعد ثابت (قوانینی که همیشه باید برقرار باشند) در این روابط چالش‌برانگیز است، به‌ویژه در دسترسی همزمان یا ذخیره‌سازی. دسترسی کنترل‌نشده به اشیاء مرتبط می‌تواند منجر به فساد داده شود.
گروه‌بندی اشیاء در مجموعه‌ها (Aggregate). مجموعه، خوشه‌ای از اشیاء مرتبط است که به‌عنوان یک واحد برای تغییرات داده در نظر گرفته می‌شود. دارای یک موجودیت ریشه است که تنها شیء قابل دسترسی از بیرون مرز مجموعه است. تمام دسترسی‌ها و تغییرات به اشیاء داخلی باید از طریق ریشه انجام شود تا ریشه بتواند قواعد را برای کل گروه اعمال کند.
استفاده از کارخانه‌ها و مخازن. ایجاد اشیاء پیچیده یا کل مجموعه‌ها ممکن است دشوار باشد؛ کارخانه‌ها منطق ایجاد را کپسوله می‌کنند و ساختار داخلی را از مشتریان پنهان می‌دارند. مخازن راهی برای بازیابی ریشه‌های مجموعه فراهم می‌کنند و جزئیات ذخیره‌سازی (مانند پرس‌وجوهای پایگاه داده) را انتزاع می‌کنند و توهم مجموعه‌ای در حافظه را ایجاد می‌کنند.
۸. مدل را به‌طور مداوم برای درک عمیق‌تر پالایش کنید
مدل‌های حوزه پیشرفته به‌ندرت جز از طریق فرایند تکراری بازسازی و با مشارکت نزدیک متخصصان حوزه و توسعه‌دهندگان علاقه‌مند به یادگیری حوزه توسعه می‌یابند.
فراتر از بازسازی فنی. بازسازی فقط بهبود ساختار کد نیست؛ بلکه با بینش‌های جدید درباره حوزه هدایت می‌شود. با تعمیق درک از طریق همکاری با متخصصان و بازخورد پیاده‌سازی، مدل نیاز به پالایش دارد. این فرایند تکراری برای توسعه مدلی واقعاً نافذ حیاتی است.
مفاهیم ضمنی را آشکار کنید. اغلب مفاهیم کلیدی حوزه در ابتدا پنهان یا ضمنی‌اند، چه در بحث‌ها و چه در بخش‌های طراحی نامناسب. گوش دادن به زبان فراگیر، شناسایی ناهماهنگی‌ها، رفع تناقض‌ها و مراجعه به منابع حوزه می‌تواند این مفاهیم را آشکار سازد. آشکارسازی آن‌ها در مدل و کد طراحی را روشن می‌کند.
بازسازی برای وضوح. نمایش صریح مفاهیمی مانند محدودیت‌ها (قواعد ثابت)، فرآیندها (عملیات پیچیده که اغلب به‌صورت سرویس پیاده‌سازی می‌شوند) و مشخصات (قوانین تست اشیاء) وضوح مدل را افزایش می‌دهد. کپسوله‌سازی این مفاهیم در اشیاء اختصاصی طراحی را ساده و قواعد کسب‌وکار را قابل مشاهده و نگهداری می‌سازد.
۹. یکپارچگی مدل را با تعریف زمینه‌های محدود حفظ کنید
حفظ یک مدل بزرگ و یکپارچه برای کل پروژه سازمانی عملی نیست.
از مدل‌های یکپارچه بزرگ پرهیز کنید. در پروژه‌های بزرگ سازمانی با تیم‌های متعدد، تلاش برای حفظ یک مدل واحد و یکپارچه در کل سیستم غیرعملی است و منجر به ناسازگاری می‌شود. کدی که بر اساس مدل‌های متمایز و غیرهمگرا نوشته شده باشد، پر از خطا و گیج‌کننده خواهد بود.
زمینه‌های محدود را تعریف کنید. راه‌حل تقسیم آگاهانه سیستم به چند مدل است که هرکدام مرز مشخصی دارند، به‌نام «زمینه محدود». در هر زمینه، مدل به‌طور دقیق و یکپارچه حفظ می‌شود و مسائل خارج از مرز اجازه آلودگی مدل داخل را ندارند.
زمینه‌ها سازماندهی را هدایت می‌کنند. زمینه‌های محدود چارچوب منطقی برای تکامل مدل و سازماندهی تیم‌ها فراهم می‌کنند. تیم‌ها می‌توانند به‌طور مستقل در زمینه خود کار کنند، مدل و پیاده‌سازی را پالایش کنند بدون نیاز مداوم به هماهنگی با دیگران، به شرطی که روابط بین زمینه‌ها به‌وضوح تعریف شده باشد.
۱۰. روابط بین زمینه‌ها را ترسیم و استراتژی‌ریزی کنید
تیم‌های نامنسجم که روی برنامه‌های مرتبط کار می‌کنند ممکن است مدتی سریع پیش بروند، اما محصول نهایی آن‌ها ممکن است با هم سازگار نباشد.
یکپارچه‌سازی زمینه‌های متمایز. در حالی که زمینه‌های محدود امکان توسعه مستقل را می‌دهند، بخش‌های مختلف سیستم باید در نهایت با هم کار کنند. تعریف روابط بین زمینه‌ها حیاتی است. نقشه زمینه سند یا نموداری است که زمینه‌های محدود مختلف و روابط صریح آن‌ها را نشان می‌دهد.
استراتژی‌های یکپارچه‌سازی را انتخاب کنید. روابط مختلف بین زمینه‌ها نیازمند استراتژی‌های متفاوت‌اند:
- هسته مشترک (Shared Kernel): تیم‌ها توافق می‌کنند زیرمجموعه‌ای از مدل و کد را به اشتراک بگذارند که نیازمند هماهنگی نزدیک و ادغام مکرر است.
- مشتری-تأمین‌کننده (Customer-Supplier): یک تیم (مشتری) به تیم دیگر (تأمین‌کننده) وابسته است. تیم مشتری بر فهرست کار تأمین‌کننده تأثیر می‌گذارد و تست‌های پذیرش خودکار رابط را اعتبارسنجی می‌کنند.
- مطیع (Conformist): تیم پایین‌دستی (مشتری) صرفاً با مدل و زبان تیم بالادستی (تأمین‌کننده) هماهنگ می‌شود و تأثیری بر آن ندارد.
مدل خود را محافظت کنید. هنگام یکپارچه‌سازی با سیستم‌های خارجی یا قدیمی، یا وقتی مدل تأمین‌کننده نامناسب است، از «لایه ضدآلودگی» (Anticorruption Layer) استفاده کنید. این لایه به‌عنوان مترجم بین دو مدل عمل می‌کند و مدل خالص حوزه شما را از آلودگی محافظت می‌کند. در غیر این صورت، اگر مزایای یکپارچه‌سازی کم است، «راه‌های جداگانه» (Separate Ways) را انتخاب کنید و کاملاً مستقل توسعه دهید.
۱۱. هسته‌ی حوزه را از زیرحوزه‌های عمومی تفکیک کنید
در طراحی سیستم‌های بزرگ، اجزای متعددی وجود دارند که ممکن است جوهره مدل حوزه، دارایی واقعی کسب‌وکار، را پنهان و نادیده بگیرند.
قلب کسب‌وکار را شناسایی کنید. در سیستم‌های بزرگ، بخش واقعاً منحصربه‌فرد و ارزشمند مدل حوزه – مزیت رقابتی یا منطق اصلی کسب‌وکار – ممکن است در میان اجزای عمومی گم شود. تقطیر فرایند جدا کردن این «هسته حوزه» از بخش‌های کم‌اهمیت‌تر است.
دغدغه‌های عمومی را جدا کنید. بسیاری از بخش‌های سیستم بزرگ، هرچند ضروری، منحصربه‌فرد حوزه کسب‌وکار نیستند. این «زیرحوزه‌های عمومی» مانند مدیریت کاربران، چارچوب‌های گزارش‌گیری یا الگوریتم‌های مسیریابی عمومی معمولاً با راه‌حل‌های آماده یا با تمرکز کمتر توسعه داده می‌شوند.
منابع را روی هسته متمرکز کنید. با شناسایی صریح هسته حوزه، تلاش توسعه و نیروی متخصص می‌تواند در آنجا متمرکز شود. بهترین مدل‌سازان و توسعه‌دهندگان باید روی هسته کار کنند و عمیق‌ترین بینش‌ها و بالاترین استانداردها را به کار گیرند. زیرحوزه‌های عمومی می‌توانند به‌صورت عملیاتی‌تر و با تیم‌های کم‌تجربه‌تر یا راه‌حل‌های استاندارد مدیریت شوند.
آخرین به‌روزرسانی::
نقد و بررسی
کتاب «طراحی مبتنی بر حوزه به‌سرعت» به‌عنوان یک مقدمه‌ی مختصر و مفید بر مفاهیم طراحی مبتنی بر حوزه شناخته می‌شود که نگاهی سریع و کلی به این موضوع برای تازه‌واردان ارائه می‌دهد. خوانندگان از کوتاهی و رویکرد ساده و مستقیم آن استقبال کرده‌اند، هرچند برخی به وجود اشتباهات دستوری و کمبود عمق در مطالب اشاره کرده‌اند. بسیاری این کتاب را نقطه‌ی شروع مناسبی پیش از مطالعه‌ی اثر جامع‌تر اریک ایوانز می‌دانند. منتقدان نیز به احساس پراکندگی و گاهی ابهام در بیان مطالب اشاره کرده‌اند. در مجموع، این کتاب برای کسانی که به دنبال درک پایه‌ای از اصول طراحی مبتنی بر حوزه هستند توصیه می‌شود، اما برای کسب بینش‌های عمیق‌تر مطالعه‌ی منابع تکمیلی پیشنهاد می‌گردد.
Similar Books
Immersive
