درک دامنه و ایجاد تیم: مبانی تغییر (II)

هنگام شروع یک پروژه پیچیده مانند پروژه ای که در حال انجام آن هستیم، ضروری است که تا آنجا که ممکن است زمینه را جمع آوری کنیم و در عین حال به دانش دامنه از ابتدا نزدیک شویم و آن را با کمک متخصصان دامنه بررسی کنیم. این فعالیت نه تنها به تیم فنی کمک می کند تا با اهداف تجاری هماهنگ شود، بلکه یک نقشه جهانی ایجاد می کند که پایه و اساس تصمیم گیری بهتر در طول چرخه عمر محصول را ایجاد می کند.

برای درک نحوه عملکرد برنامه موجود، شناسایی فرآیندهای مختلف اجرا شده و تعیین نحوه نمایش آنها در کد، ضمن ایجاد یک زبان مشترک با تیم قبلی و کاربران فعلی برنامه، جلسات اولیه ای را برگزار کردیم که چندان پربار نبود. حتی در یک مقطع به این فکر می‌کردیم که آیا می‌توانیم بدون این جلسات جلو برویم و با وجود احتمال اختلال، به تنهایی به مسائل پی ببریم.

رویداد طوفان

از ابتدای پروژه، به عنوان رهبر فناوری، با توجه به پیچیدگی پروژه و نیاز تیم به مالکیت واقعی محصول، من برای اتخاذ رویکردی مبتنی بر دامنه هم برای پروژه و هم برای تیم تلاش کردم.

این رویکرد به ما امکان داد که دامنه را در مرکز روایت قرار دهیم و کل تیم را حول یک زبان مشترک تراز کنیم (زبان فراگیر) که ارتباط را تسهیل کرد و ما را قادر ساخت تا وضعیت فعلی برنامه را ترسیم کنیم.

با در نظر گرفتن این هدف، تیم اولیه را تشکیل دادیم و شروع به آماده سازی جلسات EventStorming کردیم. این روش بصری به ما کمک کرد تا فرآیندهای کلیدی سیستم را تجزیه کنیم و رویدادها و موجودیت‌های حوزه مرتبط را شناسایی کنیم.

برای تسهیل جلسات، ما از یک الگوی Miro استفاده کردیم که راهنمایی و افسانه ای با ارجاعات کلیدی برای تمرکز موثر چنین جلساتی ارائه می کرد. اگر قصد دارید چنین جلسه ای را برگزار کنید، برای شرکت کنندگان مفید است که درک اولیه ای از مفاهیمی که با آنها کار خواهند کرد، از طریق چند پیش کار یا توضیح در ابتدای جلسه، داشته باشند.

برای به حداکثر رساندن اثربخشی این جلسات، یک فرآیند ساختاریافته را توسعه دادیم که به چند مرحله تقسیم می‌شود:

1. کاوش در رویدادهای دامنه (تصویر بزرگ)

   • رویدادهای کلیدی سیستم را شناسایی کنید.
   • آنها را به ترتیب زمانی ترتیب دهید.
   • شکاف ها و وابستگی ها را تشخیص دهید.
   • توالی را با کارشناسان دامنه تأیید کنید.

2. پالایش و تجزیه و تحلیل

   • یادداشت های توضیحی را اضافه کنید
   • شکات و سوالات را مستند کنید.
   • در هر رویداد عمیق تر کاوش کنید.
   • نکات مهم تصمیم گیری را برجسته کنید.

3. مدل سازی دامنه

   • سنگدانه ها و مرزهای آنها را شناسایی کنید.
   • بازیگران و نقش آنها را تعریف کنید.
   • دستوراتی را ایجاد کنید که فرآیندها را راه اندازی می کنند.
   • سیاست های اسناد و قوانین تجاری.
   • محرک های داخلی و خارجی را برای هر رویداد شناسایی کنید.

4. مستندسازی و اعتبارسنجی

   • اطلاعات جمع آوری شده را سازماندهی و پاکسازی کنید.
   • روابط روشنی بین عناصر برقرار کنید.
   • اعتبار مدل را با همه ذینفعان تأیید کنید.
   • مستندات مرجع ایجاد کنید

EventStorming نه تنها به ما در درک دامنه کمک کرد، بلکه به عنوان نقطه شروع درخواست نیز عمل کرد طراحی دامنه محور (DDD) اصول استراتژیک و تاکتیکی.

طراحی استراتژیک دامنه محور

یکی از مهمترین جنبه ها در مرحله اولیه پروژه، تصمیم گیری در مورد چگونگی ساختار دامنه در سطح استراتژیک بود. پیچیدگی سیستم، همراه با نیاز به همسوسازی اهداف فنی و تجاری، ما را به اتخاذ اصول طراحی دامنه محور (DDD) سوق داد.

در طی این فرآیند یکی از مفیدترین ابزارها بود نقشه برداری زمینه. اگرچه ما در حال کار با یک مونولیت بودیم که هنوز در انتظار بازسازی است، ما برای شناسایی موارد مختلف وقت گذاشتیم زمینه های محدود درون دامنه از نظر عملی، این بدان معناست که در حالی که ما چندین زمینه مفهومی را توصیف و تعریف کرده بودیم، از نظر فنی، در یک واحد عمل می‌کردیم. زمینه محدود با یک هسته مشترک این واقعیت یکپارچه مانع از بهره مندی ما از این تحلیل نشد.

اگرچه ما عمیقاً در این مورد تحقیق نکردیم نقشه برداری زمینه، استفاده از این تکنیک ها در این مرحله برای حصول اطمینان از اینکه پروژه مسیر روشنی به سمت معماری دامنه گرا دارد، حیاتی بود. این رویکرد نه تنها توسعه فنی را تسهیل کرد، بلکه باعث تقویت همکاری بهتر بین تیم های فنی و تجاری شد.

تعیین مرزها (زمینه های محدود)

شناسایی زمینه های محدود به ما کمک کرد تا درک بهتری از نحوه ارتباط بخش‌های مختلف سیستم با یکدیگر و سیستم‌های خارجی داشته باشیم. این تمرین نه تنها به ما در مدیریت کارآمدتر پیچیدگی کمک کرد، بلکه پایه روشنی برای مراحل تکاملی پروژه ایجاد کرد. با انتقال سیستم به معماری مدولارتر، این تصمیمات اولیه ما را در شکستن یکپارچه به اجزای قابل مدیریت تر و همسو با زمینه های تعریف شده راهنمایی می کند.

همچنین به ما کمک کرد تا تلاش‌های توسعه را در اولویت قرار دهیم و بخش‌هایی از سیستم را شناسایی کنیم که می‌توان آن‌ها را ساده، جدا کرد یا حذف کرد. از نظر فنی، ما روی اجرا تمرکز کردیم لایه های ضد فساد (ACL) برای تعامل با سیستم های خارجی بدون به خطر انداختن یکپارچگی سیستم ما.

در مورد ما، ما در ابتدا پنج زمینه اصلی را شناسایی کردیم:

• سفارش واگذاری
• تولید برچسب
• آماده سازی سفارش
• یکپارچه سازی تجارت الکترونیک
• آماده سازی سفارش عمده

این تصمیمات نه تنها پایه و اساس یک معماری پایدار را ایجاد کرد، بلکه تضمین کرد که فرآیندهای توسعه متمرکزتر و همسوتر با نیازهای تجاری هستند.

زبان همه جا حاضر

یکی دیگر از جنبه های کلیدی ایجاد یک زبان قوی در همه جا بود. مزایای تعریف این زبان بسیار بیشتر از تلاش اضافی ترجمه یا خطر سوء تعبیر مفاهیم است. کارشناسان و توسعه دهندگان دامنه باید فعالانه برای ایجاد این زبان مشترک، که فراتر از یک واژه نامه ساده از اصطلاحات است، همکاری کنند. این یک منبع زنده و پویا است که تیم فنی را با کارشناسان حوزه مرتبط می کند.

پیاده سازی این زبان فراگیر باعث بهبود ارتباطات، کاهش سوء تفاهم شد و تضمین کرد که کد به طور صادقانه دامنه را نشان می دهد. توسعه نرم افزار فقط یک فعالیت فنی نیست. بر اساس ارتباط و همکاری است. به لطف زبان فراگیر، همه اعضای تیم در یک راستا کار می کنند و در نتیجه راه حل های فنی کارآمدتری به دست می آید که نیازهای کسب و کار را بهتر برآورده می کند.

طراحی دامنه محور تاکتیکی

هنگامی که چارچوب استراتژیک را ایجاد کردیم، به سمت اجرای اصول تاکتیکی DDD در سیستم حرکت کردیم. این به ما اجازه داد تا کد را طوری ساختار دهیم که واقعیت دامنه را منعکس کند و از پایداری بلندمدت اطمینان حاصل کند.

موجودیت ها و اشیاء ارزشی

Entities و Value Objects دو مفهوم اساسی در طراحی Domain-Driven Design (DDD) هستند. درک تفاوت ها و نقش های آنها در حوزه بسیار مهم است.

نهادها

موجودیت ها عناصر دامنه ای با هویت منحصر به فرد هستند که در طول زمان باقی می مانند، حتی اگر ویژگی های آنها تغییر کند. این هویت منحصر به فرد آنها را از سایر عناصر هم نوع متمایز می کند. علاوه بر این، موجودیت ها معمولاً یک چرخه حیات تعریف شده در سیستم دارند. نمونه هایی از موجودیت هایی که در پروژه شناسایی کردیم عبارتند از:

• سفارش: نشان دهنده یک سفارش خرید با هویت منحصر به فرد و وضعیت مرتبط است.
• محصول: مورد کاتالوگ با ویژگی هایی مانند کد SKU، قیمت و توضیحات.
• حامل: شرکتی که مسئول تحویل سفارشات با گزینه های خدمات خاص است.
• فروشگاه: تجارت الکترونیکی یا پلتفرمی را که سفارش از آنجا شروع شده است را مشخص می کند.
• مشتری: شخص یا نهادی که سفارش دهنده و دریافت کننده محصول است.

اشیاء ارزشی

از سوی دیگر، اشیاء ارزش، عناصر دامنه بدون هویت خاص خود هستند. مقدار آنها آنها را تعریف می کند و دو Object Value با ویژگی های یکسان معادل در نظر گرفته می شوند. این آنها را تغییرناپذیر و ایده آل برای کپسوله کردن مفاهیم کلیدی می کند که ممکن است در بخش های مختلف دامنه ظاهر شوند. نمونه هایی از اشیاء ارزش در پروژه عبارتند از:

• ProductReference: کد منحصر به فرد شناسایی یک محصول.
• ProductEan13: بارکد EAN-13 مرتبط با یک محصول.
• OrderReference: شناسه منحصر به فرد برای یک سفارش.
• قیمت: با ارز و ارزش دقیق.
• وزن: با واحدهای اندازه گیری استاندارد.
• ShippingNumber: شماره شناسایی برای ردیابی.

این رویکرد به ایجاد کد قابل فهم تر و ماژولار کمک می کند، زیرا هر عنصر سیستم مسئولیت روشن و مشخصی دارد.

مثالی از یک شیء ارزشی:

readonly class ProductEan13
{
    public string $value;

    public function __construct(
        string $value
    )
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}

خدمات

در یک برنامه پیچیده مانند ما، مفهوم Services نقش اصلی را در حفظ کد تمیز و ماژولار ایفا می کند. خدمات بر اساس هدف و الگوهایی که اجرا می کنند به لایه ها و انواع مختلفی دسته بندی می شوند. بیایید نحوه سازماندهی و اجرای مؤثر خدمات را بررسی کنیم.

خدمات دامنه

خدمات دامنه منطق کسب و کار را در بر می گیرد که مستقیماً با هیچ موجودیت یا ارزش خاصی مطابقت ندارد. این خدمات کاملاً در چارچوب قوانین دامنه عمل می کنند و به اجزای زیرساخت وابسته نیستند.

class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight                          $orderWeight,
        Country                         $country,
        PostalCode                      $postalCode,
        bool                            $isCashOnDelivery = false,
    ): Carrier {
        // Lògica per obtenir el transportista més econòmic
    }
}

خدمات کاربردی

Application Services منطقی را کپسوله و هماهنگ می کند که عملیات دامنه را با تعاملات خارجی برای پیاده سازی سناریوهای تجاری یا برنامه های کاربردی خاص ترکیب می کند. این سرویس ها اجرای عملیات پیچیده را متمرکز و ساده می کنند و از جدایی واضح بین دامنه و زیرساخت اطمینان حاصل می کنند. شناخته شده ترین نمونه ها موارد استفاده هستند، اما در مورد ما نیز خواهیم داشت کنترل کننده های فرمان و گردانندگان رویداد.

موارد استفاده نشان دهنده اقدامات یا فرآیندهای خاصی است که برنامه باید انجام دهد تا نیازهای تجاری را برآورده کند. آنها منطق لازم برای اجرای عملیات پیچیده، از جمله تعامل با خدمات و زیرساخت دامنه، تمیز و متمرکز نگه داشتن دامنه را در بر می گیرند. همانطور که وان ورنون می‌گوید، می‌توان گفت که مسئولیت آنها فقط باید هماهنگی بین این دو لایه باشد و مسئولیت را به حوزه واگذار کنند. “خدمات برنامه را نازک نگه دارید و از آنها فقط برای هماهنگ کردن وظایف روی مدل استفاده کنید.”

کنترل کننده های فرمان نقطه ورود برای تغییرات در دامنه هستند. با دریافت الف فرمان، درخواست را تأیید می کنند، منطق تجاری را به مجموعه های مربوطه واگذار می کنند و در نهایت رویدادی را منتشر می کنند که منعکس کننده تغییر ایجاد شده در سیستم است.

از سوی دیگر، گردانندگان رویداد به عنوان عمل کنید شنوندگان به تغییرات در سیستم آنها به رویدادها گوش می دهند و اقدامات خاصی را در پاسخ انجام می دهند، مانند ارسال اعلان ها، به روز رسانی سایر مجموعه ها یا ادغام با سیستم های خارجی. این واکنش جدا شده امکان ساخت سیستم های انعطاف پذیرتر و مقیاس پذیرتر را می دهد. هنگامی که در مورد تکامل برنامه به عنوان یک معماری رویداد محور (EDA) و سیستم های صف صحبت می کنیم، جزئیات و مفاهیم را در نوشته های آینده توضیح خواهم داد.

readonly class NotifyShopOnOrderShipped implements EventHandlerInterface
{
    public function __construct(
        private OrderRepositoryInterface    $orderRepository,
        private ExternalOrderUpdaterFactory $externalOrderUpdaterFactory,
        private LoggerInterface             $logger
    ) {}

    public function __invoke(OrderShippedDomainEvent $event): void
    {
        // Lògica per notificar la botiga quan una comanda ha estat enviada
        $order = $this->orderRepository->findById($event->getOrderId());
        if (!$order) {
            $this->logger->error("Comanda no trobada", ['orderId' => $event->getOrderId()]);
            return;
        }

        $updater = $this->externalOrderUpdaterFactory->create($order);
        $updater->updateStatus('shipped');

        $this->logger->info("Notificació d'enviament completada", ['orderId' => $order->getId()]);
    }
}

خدمات زیرساختی

Infrastructure Services عملیاتی را اجرا می کند که به اجزای خارجی مانند پایگاه داده ها، سیستم های فایل یا خدمات شخص ثالث متکی است. آنها اغلب به عنوان آداپتورها عمل می کنند تا اطمینان حاصل کنند که دامنه نسبت به اجرای خاص آگنوستیک باقی می ماند.

class MonologLogger implements LoggerInterface
{
    private $logger;

    public function __construct(Logger $logger)
    {
        $this->logger = $logger;
    }

    public function info(string $message, array $context = []): void
    {
        $this->logger->info($message, $context);
    }

    public function warning(string $message, array $context = []): void
    {
        $this->logger->warning($message, $context);
    }

    public function critical(string $message, array $context = []): void
    {
        $this->logger->critical($message, $context);
    }

    public function error(string $message, array $context = []): void
    {
        $this->logger->error($message, $context);
    }
}

طبقه بندی خدمات

همانطور که دیدیم، سرویس ها به ما کمک می کنند تا منطق برنامه خود را به واحدهای گرانول و مستقل تر تجزیه و تجزیه کنیم. در اینجا یک طبقه بندی از سرویس های رایجی است که در پروژه خود شناسایی کرده ایم، که بر اساس عملکرد اصلی آنها گروه بندی شده و با الگوهای طراحی شناخته شده مرتبط است. این طبقه بندی نمای ساختاری تری از معماری ما ارائه می دهد و تصمیم گیری را هنگام طراحی ویژگی های جدید تسهیل می کند.

همه این مفاهیم دامنه فقط نمونه کوچکی از همه چیزهایی هستند که ما موفق به مدل سازی آن شدیم. بدیهی است که ما این کار را به یکباره انجام ندادیم و بار اول همه چیز را درست انجام ندادیم: بخش‌های زیادی وجود دارد که هنوز نیاز به بازسازی دارند، مفاهیمی که به طور کامل آنها را روشن نکرده‌ایم و مخازنی که می‌دانستیم این کار را نمی‌کنند. منطقی است، اما باید آن را برای عملکردها حفظ می‌کردیم، اما باید در نهایت آن را حذف می‌کردیم.

اما با انجام این کار اولیه، به کل تیم اجازه داد تا در این فرآیند شرکت کنند و نسبت به هر چیزی که ما می‌سازیم تعهد داشته باشند.

برای کاوش عمیق در این مفاهیم DDD و نحوه به کارگیری آنها، خواندن کتاب های زیر را توصیه می کنم:

• «طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم‌افزار» اثر اریک ایوانز: کار بنیادی روی DDD که مفاهیم موجودات و اشیاء ارزشی را به طور عمیق معرفی و توضیح می‌دهد.
• «پیاده‌سازی طراحی دامنه محور» نوشته وان ورنون: کتابی کاربردی که نمونه‌های عینی از نحوه پیاده‌سازی DDD در پروژه‌های دنیای واقعی را ارائه می‌دهد.
• “طراحی دامنه محور در PHP” توسط کارلوس بوئنوسوینوس، کریستین سورونلاس و کیوان اکبری

ساخت تیم

روند پذیرش DDD با شکل گیری و تکامل تیم همراه بود. اینجاست که می‌خواهم در مورد مدل مراحل تاکمن (1965) صحبت کنم: شکل‌گیری، طوفان، هنجارسازی، اجرا، زیرا معتقدم تکامل تیم از این توالی پیروی کرد و از یک طرف به ما کمک کرد تا تمرین‌های فنی خود را هماهنگ کنیم و در دیگر برای توسعه فرهنگ همکاری و اعتماد در تیم. همانطور که تاکمن (1965) توضیح می دهد، درک و پذیرش این مراحل کلید ایجاد تیم هایی با عملکرد بالا است. مرجع اصلی را می توان در کار او یافت: Tuckman, BW (1965). توالی رشد در گروه های کوچک. بولتن روانشناسی، 63 (6)، 384-399.

بر اساس این مدل، تیم ها برای رسیدن به حداکثر عملکرد، چهار مرحله مجزا را پشت سر می گذارند. در مرحله اولیه (شکل گیریاعضای تیم خود را معرفی کرده و اهداف کلی را تعریف می کنند. در طوفان در مرحله، با شروع تثبیت نقش ها، درگیری ها پدیدار می شوند. با گذشت زمان، در هنجارسازی در مرحله، تیم ها به یک پویایی کاری منسجم دست می یابند که در نهایت به اوج می رسد در حال اجرا، جایی که آنها به طور موثر در جهت اهداف مشترک کار می کنند.

شکل گیری

این تیم در ابتدا با دو توسعه‌دهنده تشکیل شد که شروع به بررسی پروژه و مستندسازی عملیات آن کردند، در حالی که سایر اعضا پروژه‌های مربوطه خود را برای پیوستن بستند. به نوبه خود، به عنوان یک رهبر فناوری به آن ملحق شدم و شروع به بررسی مستندات جدیدی که ایجاد شده بود و پایه‌های فنی و سازمانی پروژه و تیم را از نظر فرآیندها، استانداردها و ابزارها ایجاد کردم.

طوفان

ما نمی‌توانیم بگوییم که اختلافات عمده‌ای در تیم وجود دارد، اما ما نیاز به “تنظیم” برخی جنبه‌ها را برای همسو شدن بیشتر دیدیم. این نیاز زمانی بیشتر نمایان شد که دو نفر دیگر را به تیم اضافه کردیم و نقشه راه شکل گرفت. این ما را بر آن داشت تا به این فکر کنیم که چگونه می‌خواهیم کار کنیم، ارتباط برقرار کنیم، و مهم‌تر از همه، چگونه می‌توانیم همه این تصمیمات و دانش را در پروژه‌ای که دائماً در حال تکامل بود نمایان کنیم.

بنابراین ما به سرعت به سمت هنجارسازی مرحله ای برای ایجاد پایه های چگونگی کار و نحوه سازماندهی خودمان.

هنجارسازی

در این دوره، ما بر روی چندین جنبه برای تسهیل کار تیمی به توافق رسیدیم:

• قراردادهای تیمی: قوانین کار گروهی و ارتباطات مانند تعریف مراسم، برنامه جلسات، کانال های ارتباطی و غیره.
• استانداردهای کدگذاری: دستورالعمل هایی برای نوشتن کدهای تمیز و قابل نگهداری با پیروی از مبانی DDD، معماری شش ضلعی و اصول SOLID.
• فرآیند توسعه: تعریف ابزارها، فرآیندها و شیوه‌هایی که باید برای حفظ یک گردش کار کارآمد، با هدف بهبود کیفیت کد و بهره‌وری تیم، پرورش فرهنگ همکاری و یادگیری دنبال شوند.
• محدودیت های WIP (Work In Progress): برای اطمینان از گردش کار پایدار. به عنوان بخشی از روش ناب که به آن پرداختیم، فصل جداگانه ای برای تقویت اهمیت آن دارد.
• استقرارها: قوانینی برای استقرار کنترل شده و قابل اعتماد، از جمله محدودیت های زمانی و رویه های بازگشت.
• بدهی فنی: تعریف و مدیریت بدهی فنی انباشته و همچنین ارائه چارچوبی برای شناسایی و اولویت بندی آن در صورت لزوم.
• ADR ها: ثبت و توجیه تصمیمات معماری برای اطمینان از سازگاری و ردیابی تصمیمات اتخاذ شده.

در حال اجرا

با تمام کارهای انجام شده در مراحل قبلی، چارچوبی ایجاد کرده بودیم که به ما امکان می داد به طور کارآمد و بدون نگرانی روی توسعه محصول تمرکز کنیم، فراتر از نیاز به اولویت بندی ابتکاراتی که بیشترین ارزش را در زمینه هر لحظه ارائه می دهند. این به تیم اجازه داد تا روی اجرای عملکردهای تجاری تمرکز کند و در عین حال کیفیت کد، آموزش و زنده نگه داشتن اسناد را بهبود بخشد.

مستندات

این همه تلاش اگر به نحوی نمایان نمی شد بی معنی بود. ما آن را به گونه‌ای مستند کردیم که در هر زمان در دسترس باشد و به‌روزرسانی آسان باشد. ما از GitLab برای مدیریت کد پروژه استفاده کردیم، بنابراین عملکرد GitLab Pages را فعال کردیم و پس از کمی تحقیق از Jekyll با موضوع Just the Docs استفاده کردیم.

برای سازماندهی اطلاعات، ما خود را بر اساس مدل Diátaxis قرار دادیم:

• آموزش ها: راهنماهایی برای عملکردهای برنامه، عمدتاً برای کاربر نهایی (مثال: پیکربندی حمل و نقل).
• راهنماها: دستورالعمل ها و راه حل های عملی برای مشکلات خاص، هم برای کاربران نهایی و هم برای توسعه دهندگان (مثال: نحوه نصب برنامه).
• توضیحات: دانش عمیق از فرآیندها و استانداردهای تیم (مثال: توافق نامه های تیمی و استانداردهای کدگذاری).
• مراجع: اطلاعات دقیق برای توسعه دهندگان (به عنوان مثال: ADR ها، معماری برنامه).

مرحله بعدی که به طور کامل اجرا نکردیم، خودکارسازی اسناد فنی با استفاده از کاتالوگ رویداد و AsyncAPI بود. این به ما این امکان را می داد که اسناد را مستقیماً از پایگاه کد خود تولید کنیم و اطمینان حاصل کنیم که همیشه به روز است.