یادداشتهای مطالعه
Learning Domain-Driven Design پلی عملی بین معماری و فهم کسبوکار است.
مفید است چون DDD را به عنوان مراسم یا تمرین واژگان معرفی نمیکند. مدلسازی دامنه را راهی میداند برای فهمیدن پیچیدگی نرمافزار از کجا میآید و کجا مدلهای مختلف به مرز جدا نیاز دارند.
برای مهندسی محصول درس اصلی مستقیم است: معماری سیستم باید مسئله کسبوکار را منعکس کند، نه فقط لایهها یا سرویسهای مورد علاقه تیم مهندسی.
ایدههای مفید
از دامنه شروع کن
قبل از microservice، event sourcing، CQRS یا هر الگوی دیگر، تیم باید دامنه را بفهمد. کدام بخشها core هستند؟ کدام supporting؟ کدام آنقدر genericاند که میتوان خرید یا برونسپاری کرد؟
این تمایز جلوی overengineering در بخشهای کمارزش و کمسرمایهگذاری در جایی که مزیت محصول ساخته میشود را میگیرد.
مرزها مرز زبان هستند
bounded context فقط واحد deploy نیست. جایی است که کلمات معنی مشخص دارند. اگر دو تیم یک کلمه را با معنیهای مختلف استفاده کنند، نرمافزار احتمالاً به مرز ترجمه هم نیاز دارد.
الگوهای tactical به context نیاز دارند
transaction script، active record، domain model، event-sourced model، CQRS و saga سطح بلوغ نیستند. ابزارند. الگوی درست به پیچیدگی و نوسان منطق کسبوکار بستگی دارد.
چرا نزدیک نگهش میدارم
وقتی codebase شروع میکند مفاهیم کسبوکار را قاطی کند و هر feature coupling تصادفی بسازد مفید است. واژهای میدهد برای جدا کردن نگرانیها بدون تبدیل معماری به کار نمودار انتزاعی.
دریافت کتاب
- O'Reilly: Learning Domain-Driven Design