طراحی دامنهمحور
Domain-Driven DesignDDD یک چارچوب یا کتابخانه نیست؛ روشی است برای اینکه کد، همان چیزی را بگوید که کارشناس کسبوکار میگوید. بیشتر پروژههایی که «DDD کار میکنند» فقط پوشههایی به نام Domain ساختهاند و مدلشان همچنان کمخون است. این مسیر از زبان شروع میکند، نه از ساختار پوشه — و صادقانه میگوید کجا اصلاً به DDD نیاز نداری.
پیشرفت تو
درصد هر فصل از دو چیز میآید: چقدر از بخشهایش را خواندهای (۵۵٪) و چند تمرینش را تیک زدهای (۴۵٪). همهچیز داخل مرورگر خودت میماند.
فصل
فصلها به هم وابستهاند و ترتیبشان معنا دارد. هر مسیر با پروژههای نهایی تمام میشود: ساده، متوسط، پیچیده.
DDD چه مسئلهای را حل میکند
وقتی پیچیدگی دامنه است، نه فناوری.
در نوبت نوشتنزبان فراگیر
یک واژه، یک معنا — بین برنامهنویس و کارشناس کسبوکار.
در نوبت نوشتنطراحی راهبردی
نقشهٔ کل دامنه: هسته، پشتیبان، عمومی.
در نوبت نوشتنbounded context
مهمترین مفهوم DDD — مرزی که معنا در آن ثابت است.
در نوبت نوشتننقشهٔ زمینهها
رابطهٔ بین contextها: shared kernel، ACL، conformist.
در نوبت نوشتنentity
هویت در برابر مقدار، و چرا شناسه مهم است.
در نوبت نوشتنvalue object
بدون هویت، تغییرناپذیر — و اینکه چرا اینقدر مفید است.
در نوبت نوشتنaggregate
سختترین بخش DDD: مرز ثبات و قاعدهٔ تراکنش.
در نوبت نوشتنطراحی aggregate
قاعدههای عملی: کوچک نگه دار، با شناسه ارجاع بده.
در نوبت نوشتنرویداد دامنه
چیزی که در دامنه اتفاق افتاد، و بقیه باید بدانند.
در نوبت نوشتنdomain service و application service
منطقی که به هیچ entity تعلق ندارد.
در نوبت نوشتنrepository در DDD
مجموعهای از aggregate، نه یک لایهٔ پایگاهداده.
در نوبت نوشتنfactory
ساختن aggregate معتبر، از همان لحظهٔ اول.
در نوبت نوشتنالگوی specification
قاعدهٔ کسبوکار بهعنوان یک شیء قابل ترکیب.
در نوبت نوشتنلایهٔ ضدفساد
محافظت از مدل خودت در برابر مدل سیستم بیرونی.
در نوبت نوشتنevent sourcing
ذخیرهٔ رویدادها بهجای وضعیت — و هزینهٔ واقعیاش.
در نوبت نوشتنCQRS در کنار DDD
مدل نوشتن غنی، مدل خواندن ساده.
در نوبت نوشتنDDD و ORM
نگاشت aggregate به جدول بدون آلوده کردن دامنه.
در نوبت نوشتنتست دامنه
تست قاعدههای کسبوکار، بدون پایگاهداده و بدون mock.
در نوبت نوشتنضدالگوها
مدل کمخون، aggregate غولآسا، و DDD کاغذی.
در نوبت نوشتنکِی DDD نزن
CRUD ساده به DDD نیاز ندارد — و این را باید بپذیری.
در نوبت نوشتنپروژهٔ ۱ — مدلسازی یک دامنه
از گفتوگو با کارشناس تا entity و value object.
در نوبت نوشتنپروژهٔ سادهپروژهٔ ۲ — aggregate و رویداد
مرز ثبات، invariant و رویداد دامنه، با تست کامل.
در نوبت نوشتنپروژهٔ متوسطپروژهٔ ۳ — دو bounded context
دو زمینه، نقشهٔ رابطه، ACL و سازگاری نهایی.
در نوبت نوشتنپروژهٔ پیچیده