مفتخریم به اطلاع برسانیم که سومین جلسه کارگاه Exploratory Domain Discovery (#EDD) مثل ۲ جلسه گذشته با استقبال گرم شما عزیزان برگزار شد.

در این کارگاه @masodbahrami ما رو با روش جدیدی آشنا میکنه که با اون بتونیم به درک عمیقی از domain و پیچیدگی هاش برسیم.

این رویداد با همکاری شرکت Asan Pardakht و Pargan صورت گرفت و جا داره یک تشکر ویژه از این ۲ مجموعه Soheil Karami، Ali Erfagh و Sepehr Namdar داشته باشیم که پشت صحنه بسیار به ما کمک کردند.

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

انجمن DDD ایران در نظر دارد تا چهارمین جلسه آنلاین کارگاه
EDD (Exploratory Domain Discovery)
را در تاریخ جمعه ۳ اسفند ماه به صورت آنلاین برگزار نماید.

جهت کسب اطلاعات بیشتر و ثبت‌ نام می‌توانید به لینک زیر مراجعه فرمایید :
https://exploratorydomaindiscovery.com/b/edd-4th-workshop-online/

نظرسنجی دوره‌های آموزشی بهار ۱۴۰۴

به منظور برگزاری هر چه بهتر دوره‌های آموزشی، در نظر داریم نظرات شما را در خصوص برنامه‌های آموزشی بهار ۱۴۰۴ را دریافت کنیم. خواهشمندیم با اعلام دوره‌ی مورد علاقه‌ی خود، ما را در تنظیم برنامه‌های دقیق و متناسب با نیازهای خودتان یاری نمایید.

🔹دوره Domain-Driven Design
برای آن دسته از توسعه‌دهندگان باتجربه طراحی شده است که علاقه‌مند به درک عمیق اصول و تکنیک‌های طراحی سیستم‌های پیچیده هستند. در این دوره، تمامی جنبه‌های کلیدی DDD از مبانی نظری تا تکنیک‌های عملی مورد بررسی قرار می‌گیرد و شما با مفاهیم بنیادین مدل‌سازی دامنه، تعریف و شناسایی Bounded Contextها و ضرورت شکل‌گیری Ubiquitous Language آشنا خواهید شد. سپس با الگوهای طراحی تکنیکال آشنا خواهید شد که به شما کمک می کند تا ساختاردهی کد را به گونه‌ای انجام دهید که با پیچیدگی‌های واقعی در نیازمندی‌های کسب‌وکار همگام باشد.
این دوره توانمندی‌های شما در مدل‌سازی سیستم‌های پیچیده را به سطحی بالاتر ارتقا می‌دهد و در پایان این دوره، قادر خواهید بود با دیدی تحلیلی و رویکردی استراتژیک، مدل‌های پیچیده را به شکلی منسجم و قابل نگهداری پیاده‌سازی کنید.


🔸دوره Domain-Driven Design برای مالکان محصول و تحلیل‌گران
این دوره به بررسی دقیق جنبه‌های تحلیلی و مفهومی DDD می‌پردازد و از تکنیک‌های Context Mapping, Event Storming و Domain Storytelling برای ترجمه نیازمندی‌های کسب‌وکار به مدل‌های دامین شفاف و قابل فهم برای تیم‌های فنی استفاده می‌کند.
این دوره برای تحلیل‌گران و Product Ownerهایی طراحی شده است که می‌خواهند شکاف موجود بین ذینفعان کسب‌وکار و تیم‌های توسعه را از طریق تعریف دقیق نیازمندی‌ها کاهش دهند.


🔹دوره الگوهای طراحی سیستم‌های واکنشی (Reactive Systems)
این دوره برای توسعه‌دهندگان و معمارانی است که می‌خواهند با الگوهای پیاده‌سازی سیستم‌های توزیع‌شده با کارایی بالا، مقیاس‌پذیری مطلوب و تحمل خطای بالا آشنا شوند. در این دوره، به بررسی عمیق اصول و مفاهیم کلیدی مانند ارتباطات غیرهمزمان، الگوی Event Sourcing، معماری CQRS و طراحی مبتنی بر پیام (Message-Driven Architecture) پرداخته می‌شود.

شرکت‌کنندگان با مفاهیم کلیدی همچون Resilience، Scalability و Responsiveness در معماری‌های توزیع‌شده و همچنین با راهکارهای مدرن برای طراحی سیستم‌های High Throughput و Low Latency در سناریوهای Real-time و داده‌محور آشنا خواهند شد.


🔸دوره آشنایی با تحلیل و طراحی شی‌گرا
این دوره با تأکید بر اصول GRASP، به آن دسته از اصول و الگوهای طراحی می‌پردازد که هدفشان تخصیص بهینه مسئولیت‌ها به کلاس‌ها و اشیاء است. شرکت‌کنندگان دوره می‌آموزند که چگونه کدهایی با انعطاف‌پذیری بالا، قابلیت استفاده مجدد (Reusability) و تست‌پذیری بهتر بنویسند.
این دوره برای توسعه‌دهندگان و معمارانی که به دنبال ارتقای مهارت‌های مدل‌سازی شی‌گرا و اجرای صحیح اصول SOLID در پروژه‌هایشان هستند، طراحی شده است.


لینک شرکت در نظرسنجی:
https://forms.gle/BymS3SN6UWAgYGxM6

- انجمن DDD ایران
@DDD_IRAN

مدل‌سازی مشارکتی (Collaborating Modeling) رویکردی در مهندسی نرم‌افزار است که در آن ذی‌نفعان مختلف، از جمله توسعه‌دهندگان، طراحان، تحلیلگران، و کاربران نهایی، به‌صورت تیمی برای ایجاد مدل‌های سیستم با یکدیگر همکاری می‌کنند. این روش بر بهبود ارتباطات، شفافیت و درک مشترک از سیستم تمرکز دارد.

۱. برای توسعه چه نوع سیستم‌هایی مناسب است؟
مدل‌سازی مشارکتی میتواند برای توسعه سیستم‌های زیر مناسب باشد:

🔹 سیستم‌های پیچیده: پروژه‌هایی با نیازمندی‌های متنوع و ذی‌نفعان متعدد، مانند سیستم‌های بانکی یا مدیریت زنجیره تأمین.
🔹 سیستم‌های کاربرمحور: نرم‌افزارهایی که تجربه کاربری (UX) در آن‌ها اهمیت بالایی دارد، مانند اپلیکیشن‌های موبایل.
🔹 پروژه‌های نوآورانه: جایی که نیازمندی‌ها به‌مرور زمان کشف و تکامل می‌یابند و عموما از یک متدولوژی چابک برای توسعه بهره می‌برند.

۲. چه مقدماتی لازم دارد؟
برای پیاده‌سازی موفق مدل‌سازی مشارکتی، موارد زیر ضروری است:

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

۳. چند تکنیک شناخته‌شده

۱. User Story Mapping

توضیح: تکنیکی برای ترسیم داستان‌های کاربر (User Stories) به‌صورت بصری برای درک جریان کاری و اولویت‌بندی نیازمندی‌ها.
کاربرد: کمک به تیم برای شناسایی نیازهای کاربر و ایجاد نقشه راه محصول.
ویژگی: ساده، کاربرمحور و مناسب برای تیم‌های چابک.

۲. Event Storming

توضیح: روشی برای کشف و مدل‌سازی فرآیندهای کسب‌وکار با تمرکز بر رویدادها (Events) و تعاملات.
کاربرد: ایده‌آل برای تحلیل سیستم‌های توزیع‌شده یا فرآیندهای پیچیده.
ویژگی: مشارکتی، بصری و سریع برای شناسایی گلوگاه‌ها.

۳. Impact Mapping

توضیح: Impact Mapping یک تکنیک مشارکتی برای ترسیم اهداف کسب‌وکار، اقدامات کاربران، و ویژگی‌های سیستم به‌صورت بصری است. این روش با تمرکز بر "چرا" (هدف)، "چه کسی" (کاربران)، "چگونه" (رفتارها) و "چه" (ویژگی‌ها) به تیم کمک می‌کند تا نیازمندی‌ها را اولویت‌بندی کند.
کاربرد: مناسب برای پروژه‌های چابک و محصول‌محور که نیاز به هم‌راستایی بین اهداف کسب‌وکار و توسعه نرم‌افزار دارند.
ویژگی: ساده، بصری، و ایده‌آل برای جلسات تیمی با حضور ذی‌نفعان غیرفنی و فنی. این تکنیک به‌ویژه در متدولوژی‌های چابک محبوب است و به تیم‌ها کمک می‌کند تا روی ارزش واقعی محصول تمرکز کنند.

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

- انجمن DDD ایران
@DDD_IRAN

اهمیت تصمیمات استراتژیک در طراحی: نگاهی از منظر Domain-Driven Design

▫️دو سطح تصمیم‌گیری در طراحی
در دنیای پیچیده طراحی نرم‌افزار، ما همواره با دو سطح متمایز از تصمیم‌گیری مواجه هستیم: تصمیمات استراتژیک و تصمیمات تکنیکال. این تمایز، به‌ویژه در رویکرد Domain-Driven Design (DDD)، از اهمیت حیاتی برخوردار است. تصمیمات استراتژیک به «انجام کار درست» مربوط می‌شوند، در حالی که تصمیمات تکنیکال بر «درست انجام دادن کار» متمرکز هستند.

▫️ماهیت تصمیمات استراتژیک
تصمیمات استراتژیک در طراحی، آن‌هایی هستند که مسیر کلی سیستم را تعیین می‌کنند. این تصمیمات شامل شناسایی هسته‌های کسب‌وکار (Core Domains)، تعیین مرزهای محدوده‌ها (Bounded Contexts) و انتخاب الگوهای ارتباطی بین این محدوده‌ها می‌شوند. این‌ها تصمیماتی هستند که اگر اشتباه گرفته شوند، هیچ مقدار از پیاده‌سازی فنی دقیق نمی‌تواند سیستم را از شکست نجات دهد.

"استراتژی غلط با تکنیک عالی، فقط راه اشتباه را با کارایی بالا طی می‌کند." - اریک اوانز

▫️اهمیت استراتژی برتر از تکنیک
۱. تقدم ذاتی هدف بر وسیله: حتی اگر تمام اصول SOLID را به‌درستی رعایت کنید، اگر در محدوده اشتباهی سرمایه‌گذاری کرده باشید، نتیجه نهایی ارزش کسب‌وکاری نخواهد داشت.

۲. هزینه اصلاح ناهمگونی: تغییر در تصمیمات استراتژیک پس از پیاده‌سازی، معمولاً مستلزم بازنویسی اساسی سیستم است، در حالی که مشکلات تکنیکال اغلب با بازسازی‌های موضعی قابل‌حل هستند.

۳. تأثیر سیستمی: یک تصمیم استراتژیک غلط می‌تواند تمام جنبه‌های سیستم را تحت تأثیر قرار دهد، در حالی که خطاهای تکنیکال معمولاً محدود به بخش‌های خاصی باقی می‌مانند.

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

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

- انجمن DDD ایران
@DDD_IRAN

دو ابزار مکمل برای فهم و حل مسائل پیچیده: ‌Wardley Mapping و Domain-Driven Design

در دنیای توسعه نرم‌افزار، Domain-Driven Design (DDD) رویکردی موفق برای مدل‌سازی سیستم‌های پیچیده است. اما همیشه یک سؤال اساسی وجود دارد: کدام بخش از سیستم واقعاً ارزش سرمایه‌گذاری دارد؟

اینجاست که Wardley Mapping وارد صحنه می‌شود؛ ابزاری برای تحلیل استراتژیک که به ما کمک می‌کند تصمیم‌های طراحی را نه از روی حدس و گمان، بلکه بر اساس درک عمیق از ارزش و بلوغ مؤلفه‌ها اتخاذ کنیم.

۱. یافتن Core Domain با عینک استراتژیک Wardley
در DDD، شناسایی Core Domain (بخشی از سیستم که مزیت رقابتی ایجاد می‌کند) حیاتی است. اما این شناسایی معمولاً با چالش همراه است. Wardley Mapping کمک می‌کند با ترسیم زنجیره ارزش (Value Chain) و جای‌گذاری مؤلفه‌ها روی نقشه، مشخص کنیم که:

🔸 کدام مؤلفه‌ها در مراحل اولیه تکامل هستند (Genesis یا Custom-Built)؛ یعنی جایی که نوآوری و مزیت رقابتی شکل می‌گیرد.
🔸 و کدام‌ها به مرحله کالا رسیده‌اند (Commodity) و ارزش سرمایه‌گذاری خاصی ندارند.

📌 نتیجه: تمرکز منابع بر Core Domainهایی که واقعاً تفاوت ایجاد می‌کنند، نه بخش‌هایی که می‌توان به راحتی خرید یا برون‌سپاری کرد.

۲. انتخاب استراتژی طراحی متناسب با بلوغ مؤلفه‌ها
در Wardley Mapping، هر مؤلفه نرم‌افزاری در یکی از مراحل تکامل قرار دارد—از نوآوری خالص (Genesis) تا کالای استاندارد (Commodity)—و این مراحل باید مستقیماً بر تصمیم‌های طراحی در Domain-Driven Design اثر بگذارند. مؤلفه‌هایی که در مرحله Genesis هستند، معمولاً بخشی از Core Domain محسوب می‌شوند و نیاز به مدل‌سازی دقیق، معماری منعطف و تیم متخصص دارند. مؤلفه‌های Custom-Built نیز در حال بلوغ‌اند و باید با ساختارهایی توسعه‌پذیر و قابل تغییر طراحی شوند. در مقابل، مؤلفه‌هایی که به سطح Product رسیده‌اند، معمولاً Supporting Subdomain هستند و می‌توان از ابزارهای موجود برای آن‌ها استفاده کرد. نهایتاً مؤلفه‌های کالایی‌شده (Commodity) که ارزش تمایز ندارند، بهتر است با سرویس‌های آماده یا برون‌سپاری پوشش داده شوند. این رویکرد باعث می‌شود منابع فنی و طراحی فقط جایی صرف شوند که واقعاً مزیت رقابتی ایجاد می‌کنند.

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

📌 مزیت: جلوگیری از طراحی‌های پیچیده برای بخش‌هایی که نیاز به خلاقیت یا تفاوت ندارند.

۳. تعیین دقیق‌تر مرزهای Bounded Context
یکی از چالش‌های DDD، کشیدن مرزهای مناسب بین مدل‌هاست. Wardley Mapping با شفاف‌سازی وابستگی‌ها و نرخ تغییر مؤلفه‌ها، کمک می‌کند:

🔸مؤلفه‌هایی که در مراحل متفاوت تکامل هستند، بهتر است در Bounded Contextهای مجزا قرار بگیرند.
🔸مؤلفه‌هایی با سرعت تغییر بالا (مثل Core Domain) نیاز به حفاظ طراحی (Anti-Corruption Layer) دارند تا از اثرپذیری از مؤلفه‌های پایدارتر جلوگیری شود.

۴. انتخاب معماری بر اساس ارزش و بلوغ
با ترکیب دیدگاه DDD و Wardley Mapping، تصمیم‌گیری درباره معماری سیستم شفاف‌تر می‌شود:

🔸برای Core Domainهای متغیر و نوآورانه 👈🏻 میکروسرویس‌ها
🔸برای Supporting Subdomains با ثبات 👈🏻 مونولیت‌های ماژولار
🔸برای Generic Subdomains استاندارد 👈🏻 سرویس‌های SaaS یا APIهای آماده

📌 این یعنی: معماری باید تابع ارزش باشد، نه مُد یا هیجان فناوری.

جمع‌بندی: هماهنگی DDD و Wardley برای طراحی هوشمندانه‌تر
ترکیب Wardley Mapping و DDD مثل همراهی یک استراتژیست و یک معمار است:

🔸آنچه که Wardley Mapping می‌گوید: کجا و چرا باید سرمایه‌گذاری کرد.
🔸آنچه که DDD می‌گوید: چطور آن سرمایه‌گذاری را به سیستم نرم‌افزاری تبدیل کنیم.

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

کسب اطلاعات بیشتر: https://learnwardleymapping.com/introduction/

- انجمن DDD ایران
@DDD_IRAN

اوانس در کتاب مشهور خود، چند الگو را برای دستیابی به Supple Design مورد تاکید قرار می‌دهد. هدف از این تاکیدات، دستیابی به نوعی از طراحی است که نه‌تنها کد خواناتر باشد، بلکه تغییرات آینده نیز با هزینه کمتری انجام شوند. یکی از آن الگوها، بستار عملیات (Closure of Operations) است.

بستار عملیات (Closure of Operations) چیست؟

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

برای مثال، فرض کنید در یک سیستم مالی با یک کلاس Money کار می‌کنید که نشان‌دهنده مقدار پول با یک ارز خاص است. اگر عملیاتی مانند جمع (add) تعریف کنید، این عملیات باید دو شیء Money را بگیرد و نتیجه‌اش نیز یک شیء Money باشد:

Money add(Money a, Money b) {
    // اطمینان از یکسان بودن ارزها
    return new Money(a.amount + b.amount, a.currency);
}

در اینجا، عملیات add بسته است، زیرا خروجی آن همچنان یک Money است و نیازی به ایجاد نوع جدیدی (مثلاً یک نوع عمومی یا یک ساختار متفاوت) نیست. این ویژگی باعث می‌شود که عملیات‌ها به‌صورت طبیعی در زنجیره‌های بزرگ‌تر یا ترکیب‌های پیچیده‌تر استفاده شوند، بدون اینکه مدل دامنه را پیچیده‌تر کنند.

چرا Closure of Operations مفید است؟

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

▫️افزایش قابلیت ترکیب‌پذیری:
وقتی عملیات‌ها بسته هستند، می‌توان آن‌ها را به‌راحتی با یکدیگر ترکیب کرد. برای مثال، در همان سیستم مالی، می‌توانید عملیاتی مانند add و multiply را پشت سر هم استفاده کنید:

Money total = account1.balance.add(account2.balance).multiply(taxRate);

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

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

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

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

مثال عملی

فرض کنید در یک سیستم مدیریت موجودی انبار، کلاسی به نام Quantity دارید که نشان‌دهنده تعداد اقلام است. اگر عملیاتی مانند increase (افزایش موجودی) یا decrease (کاهش موجودی) تعریف کنید، این عملیات‌ها باید خروجی‌ای از نوع Quantity تولید کنند:

Quantity increase(Quantity current, Quantity amount) {
    return new Quantity(current.value + amount.value);
}

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

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

- انجمن DDD ایران
@DDD_IRAN

در رویکرد DDD، زبان همه‌جایی (Ubiquitous Language) به‌عنوان پلی میان مفاهیم کسب‌وکار و پیاده‌سازی نرم‌افزاری عمل می‌کند. این زبان از دامنه‌ی کسب‌وکار سرچشمه می‌گیرد و تضمین می‌کند که مدل نرم‌افزار با نیازهای واقعی هم‌راستا باشد. اما آیا این جریان صرفاً از فضای مسئله (دامنه) به فضای راه‌حل (نرم‌افزار) است؟ خیر، تعامل بین این دو فضا کاملاً دوسویه است و مفاهیم نرم‌افزاری نیز به زبان و حتی تفکر کسب‌وکاری نفوذ می‌کنند.

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

چرا این تعامل دوسویه ارزشمند است؟

🔸غنی‌سازی زبان دامنه: مفاهیم نرم‌افزاری می‌توانند زبان کسب‌وکار را دقیق‌تر و منسجم‌تر کنند. برای مثال، اصطلاحاتی مانند «اتوماسیون فرآیند» یا «تحلیل بلادرنگ» که ریشه‌ی فنی دارند، به کسب‌وکارها کمک کرده‌اند تا فرآیندهای خود را بهتر تعریف و بهینه کنند.

🔸نوآوری در کسب‌وکار: فناوری می‌تواند راه‌های جدیدی برای حل مسائل پیشنهاد دهد. مفهوم «پیشنهادهای شخصی‌سازی‌شده» که از یادگیری ماشین سرچشمه گرفته، نمونه‌ای از تأثیر فناوری بر تحول در بازاریابی و فروش است.

🔸تقویت همکاری: وقتی زبان دامنه و مفاهیم فنی به‌صورت دوسویه بر هم اثر می‌گذارند، گفت‌وگو بین توسعه‌دهندگان و کارشناسان دامنه روان‌تر می‌شود و درک متقابل از محدودیت‌ها و امکانات افزایش می‌یابد.

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

- انجمن DDD ایران
@DDD_IRAN

معرفی Domain Vision Statement

بیانیه چشم‌انداز دامنه (Domain Vision Statement) یک بیانیه مختصر و استراتژیک است که هدف اصلی، ارزش پیشنهادی و تمرکز یک دامنه (Domain) خاص در یک پروژه یا سیستم نرم‌افزاری را توصیف می‌کند. این بیانیه به‌عنوان یک راهنمای کلیدی در فرآیند توسعه عمل می‌کند و به تیم‌ها کمک می‌کند تا بدون نیاز به غرق شدن در جزئیات پیچیده مدل دامنه، درک روشنی از اهمیت و جهت‌گیری آن داشته باشند.

چرا به Domain Vision Statement نیاز داریم؟

در ابتدای یک پروژه، معمولاً مدل دامنه هنوز شکل نگرفته است، اما نیاز به تمرکز بر توسعه آن وجود دارد. در مراحل بعدی، زمانی که مدل دامنه پیچیده‌تر می‌شود، توضیح ارزش سیستم بدون نیاز به مطالعه عمیق مدل ضروری است. علاوه بر این، جنبه‌های کلیدی دامنه ممکن است چندین Bounded Context (محدوده‌های مشخص) را در بر بگیرند، اما این محدوده‌ها به‌گونه‌ای طراحی شده‌اند که نمی‌توانند به‌صورت یکپارچه تمرکز مشترک را نشان دهند. Domain Vision Statement این شکاف را پر می‌کند.

ویژگی‌های اصلی Domain Vision Statement

🔹مختصر و متمرکز: این بیانیه کوتاه (حدود یک صفحه) است و تنها بر جنبه‌های اصلی و متمایز دامنه تمرکز دارد، بدون پرداختن به جزئیات غیرضروری.

🔹ارزش پیشنهادی: به‌وضوح توضیح می‌دهد که دامنه چه ارزشی برای سازمان، کاربران یا ذی‌نفعان ایجاد می‌کند.

🔹تعادل بین منافع متنوع: نشان می‌دهد که چگونه دامنه نیازها و منافع مختلف (مثل کاربران، کسب‌وکار و تیم‌های فنی) را متعادل می‌کند.

🔹انعطاف‌پذیر و قابل بازبینی: این بیانیه در ابتدای پروژه نوشته می‌شود و با کسب بینش‌های جدید در طول توسعه بازبینی و بهبود می‌یابد.

نقش در Domain-Driven Design (DDD)

در چارچوب Domain-Driven Design (DDD)، این بیانیه به‌عنوان یک ابزار استراتژیک عمل می‌کند که:

🔸 جهت‌گیری دامنه را مشخص می‌کند و از پراکندگی تلاش‌ها جلوگیری می‌کند.
🔸 به تعریف Ubiquitous Language (زبان مشترک) و Bounded Context کمک می‌کند.
🔸 هم‌راستایی بین مدل دامنه و اهداف کسب‌وکار را تضمین می‌کند.

مثال ساده

برای یک دامنه "مدیریت سفارشات" در یک پلتفرم تجارت الکترونیک:

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

نتیجه

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

- انجمن DDD ایران
@DDD_IRAN

تاریخچه Domain Modeling

مدل‌سازی دامنه (Domain Modeling) یکی از مفاهیم کلیدی در مهندسی نرم‌افزار است که به طراحی و توسعه سیستم‌های نرم‌افزاری با تمرکز بر درک عمیق دامنه مسئله کمک می‌کند. این رویکرد به ایجاد مدل‌هایی از مفاهیم، اشیاء و روابط موجود در یک دامنه خاص می‌پردازد تا نرم‌افزار به شکلی مؤثرتر و دقیق‌تر نیازهای کاربران را برآورده کند. تاریخچه مدل‌سازی دامنه ریشه در تکامل مهندسی نرم‌افزار و نیاز به مدیریت پیچیدگی‌های روزافزون سیستم‌ها دارد.

ریشه‌ها: دهه‌های 1960 و 1970
مدل‌سازی دامنه به‌صورت رسمی در دهه‌های 1960 و 1970 شکل نگرفت، اما مفاهیم اولیه آن در روش‌های برنامه‌نویسی ساخت‌یافته و تحلیل سیستم‌ها دیده می‌شود. در این دوره، مهندسان نرم‌افزار با چالش‌های طراحی سیستم‌های بزرگ‌تر مواجه شدند. نیاز به درک بهتر دامنه‌های مسئله، مانند سیستم‌های بانکی، صنعتی یا علمی، باعث شد که تحلیلگران شروع به مستندسازی موجودیت‌ها و روابط بین آن‌ها کنند. این کار به نوعی پیش‌زمینه‌ای برای مدل‌سازی دامنه بود.
یکی از تأثیرات مهم این دوره، ظهور مفاهیم مدل‌سازی داده‌ها بود. با معرفی پایگاه‌های داده رابطه‌ای توسط ادگار کاد (Edgar F. Codd) در سال 1970، مدل‌سازی موجودیت‌ها و روابط آن‌ها به شکلی ساخت‌یافته‌تر انجام شد. این مدل‌ها به توسعه‌دهندگان کمک کردند تا داده‌های دامنه را به‌صورت منطقی سازمان‌دهی کنند.

دهه 1980: ظهور برنامه‌نویسی شیءگرا
دهه 1980 نقطه عطفی در تاریخچه مدل‌سازی دامنه بود. با ظهور برنامه‌نویسی شیءگرا (Object-Oriented Programming) و زبان‌هایی مانند Smalltalk و سی‌پلاس‌پلاس، مفهوم مدل‌سازی دامنه به شکلی پیشرفته‌تر مطرح شد. در این رویکرد، مفاهیم دامنه به‌صورت اشیاء (Objects) مدل‌سازی شدند که شامل داده‌ها (ویژگی‌ها) و رفتارها (متدها) بودند. این روش امکان بازنمایی دقیق‌تری از دامنه‌های واقعی را فراهم کرد.
در همین دوره، متدولوژی‌های طراحی شیءگرا مانند OMT (Object Modeling Technique) و روش‌های بووچ (Booch Method) معرفی شدند. این متدولوژی‌ها بر ایجاد مدل‌هایی از دامنه تأکید داشتند که نه‌تنها داده‌ها، بلکه رفتارها و تعاملات را نیز شامل می‌شدند. این مدل‌ها به توسعه‌دهندگان کمک کردند تا سیستم‌هایی منسجم‌تر و قابل‌نگهداری‌تر طراحی کنند.

دهه 1990: شکل‌گیری UML و DDD
دهه 1990 شاهد پیشرفت‌های چشمگیری در مدل‌سازی دامنه بود. یکی از مهم‌ترین تحولات این دوره، معرفی زبان مدل‌سازی یکپارچه (Unified Modeling Language - UML) بود. UML، که توسط گریدی بووج، جیمز رامبو و ایوار یاکوبسون توسعه یافت، به‌عنوان یک استاندارد برای مدل‌سازی نرم‌افزارهای شیءگرا پذیرفته شد. نمودارهای UML، مانند نمودار کلاس و نمودار مورد استفاده (Use Case)، ابزارهای قدرتمندی برای نمایش دامنه‌های پیچیده فراهم کردند.

در اواخر دهه 1990 و اوایل دهه 2000، مفهوم طراحی مبتنی بر دامنه (Domain-Driven Design - DDD) توسط اریک اوانز (Eric Evans) معرفی شد. کتاب او با عنوان Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) به یکی از مراجع اصلی این حوزه تبدیل شد. DDD بر تمرکز عمیق بر دامنه، همکاری نزدیک با کارشناسان دامنه و ایجاد یک زبان مشترک (Ubiquitous Language) بین توسعه‌دهندگان و ذی‌نفعان تأکید داشت. این رویکرد، مدل‌سازی دامنه را از یک فعالیت صرفاً فنی به یک فرآیند مشترک و استراتژیک تبدیل کرد.

دهه 2000 و پس از آن: تکامل و پذیرش گسترده
با معرفی DDD، مدل‌سازی دامنه به‌عنوان یک رویکرد استراتژیک در توسعه نرم‌افزارهای پیچیده مورد توجه قرار گرفت. مفاهیمی مانند (Entities)، (Value Objects)، (Domain Services) و زمینه‌های محدود (Bounded Contexts) به توسعه‌دهندگان کمک کردند تا سیستم‌های مقیاس‌پذیر و قابل‌نگهداری طراحی کنند.

در دهه 2010، با گسترش معماری‌های میکروسرویس، مدل‌سازی دامنه اهمیت بیشتری یافت. DDD به‌ویژه در تعریف زمینه‌های محدود برای تفکیک سرویس‌ها و مدیریت پیچیدگی‌های سیستم‌های توزیع‌شده بسیار مؤثر بود. ابزارهای مدل‌سازی مانند Event Storming نیز در این دوره محبوب شدند که به تیم‌ها کمک می‌کردند تا جریان‌های کاری و رویدادهای دامنه را به‌صورت بصری مدل‌سازی کنند.
امروزه، مدل‌سازی دامنه در کنار فناوری‌های مدرن مانند کلان‌داده، هوش مصنوعی و سیستم‌های ابری همچنان در حال تکامل است.

- انجمن DDD ایران
@DDD_IRAN

آشنایی با تکنیک Domain Storytelling: پلی برای فهم مشترک

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

پیشنهاد می‌کنیم تکنیک Domain Storytelling را بیازمایید. روشی که نه تنها دانش را منتقل می‌کند، بلکه داستان‌گویی را به ابزاری برای خلق فهم مشترک تبدیل می‌سازد.

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

اجزای یک داستان دامنه
هر داستان از عناصری ساده اما قدرتمند تشکیل شده است:

🔹بازیگران (Actors): انسان‌ها یا سیستم‌هایی که در فرآیند نقش دارند، از کارمند ساده گرفته تا یک نرم‌افزار اتوماسیون.

🔹فعالیت‌ها (Activities): کارهایی که انجام می‌شوند، مانند «ثبت سفارش» یا «ارسال ایمیل تأیید».

🔹اشیاء کاری (Work Objects): چیزهایی که در فرآیند جابه‌جا یا تغییر می‌کنند، مانند یک فرم سفارش یا یک بسته پستی.

🔹رویدادها: نقاط عطفی که نشان‌دهنده اتفاقات مهم در جریان کار هستند.

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

چرا Domain Storytelling؟
شاید بپرسید چرا باید به جای روش‌های سنتی تحلیل، به سراغ داستان‌گویی رفت؟ پاسخ در سادگی و قدرت ارتباطی این روش نهفته است. در جهانی که سوءتفاهم‌ها بین تیم‌های فنی و غیرفنی پروژه‌ها را به تأخیر می‌اندازند، Domain Storytelling به‌عنوان پلی عمل می‌کند که شکاف‌های ارتباطی را پر می‌کند. این تکنیک به ذی‌نفعان اجازه می‌دهد تا نه تنها فرآیندها را بهتر درک کنند، بلکه ناسازگاری‌ها، گلوگاه‌ها یا حتی فرصت‌های بهبود را شناسایی کنند.
برای مثال، تصور کنید یک شرکت تجارت الکترونیک در تلاش است تا فرآیند تحویل کالا را بهبود بخشد. با استفاده از Domain Storytelling، تیم می‌تواند داستان سفر یک سفارش از لحظه ثبت تا رسیدن به دست مشتری را ترسیم کند. در این فرآیند، ممکن است متوجه شوند که تأخیر در انبار به دلیل فقدان یک سیستم اطلاع‌رسانی خودکار است. این بینش، که از دل یک داستان ساده بیرون آمده، می‌تواند به تغییرات واقعی در کسب‌وکار منجر شود.

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

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

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

- انجمن DDD ایران
@DDD_IRAN

هوش مصنوعی به‌عنوان اردک پلاستیکی: تقویت خلاقیت در مهندسی نرم‌افزار

در دنیای مهندسی نرم‌افزار، تکنیک «اردک پلاستیکی» (Rubber Duck Debugging) به‌عنوان روشی ساده اما قدرتمند برای حل مسائل شناخته می‌شود. برنامه‌نویسان با توضیح مشکل خود به یک شیء بی‌جان، مانند یک اردک پلاستیکی، اغلب به راه‌حل می‌رسند. اما چه می‌شود اگر این اردک بتواند پاسخ دهد، سؤال بپرسد یا حتی ایده‌های جدید پیشنهاد کند؟ برخی معتقدند که هوش مصنوعی (AI) می‌تواند نقش یک «اردک پلاستیکی سخنگو» را ایفا کند و خلاقیت را در فرآیند توسعه نرم‌افزار تقویت کند.

تکنیک اردک پلاستیکی چیست؟
تکنیک اردک پلاستیکی ریشه در یک ایده ساده دارد: وقتی برنامه‌نویسان مشکل خود را با صدای بلند برای یک شنونده غیرانسانی توضیح می‌دهند، مجبور می‌شوند مسئله را به شکلی واضح و ساختاریافته بیان کنند. این فرآیند خود-بازبینی اغلب به شناسایی خطاها یا دیدگاه‌های جدید منجر می‌شود. اردک پلاستیکی نیازی به پاسخ دادن ندارد؛ نقش آن صرفاً ایجاد فضایی برای تفکر است.

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

🔹تعامل فعال داشته باشد: AI می‌تواند سؤالاتی هدفمند بپرسد یا نکاتی را برجسته کند که برنامه‌نویس ممکن است نادیده گرفته باشد.

🔹ایده‌های جدید پیشنهاد دهد: با دسترسی به دانش گسترده، AI می‌تواند راه‌حل‌های جایگزین یا نمونه‌هایی از پروژه‌های مشابه ارائه دهد.

🔹همدلی شبیه‌سازی کند: لحن همدلانه یا پرس‌وجوهای تشویقی AI می‌تواند برنامه‌نویسان را به کاوش عمیق‌تر مسائل ترغیب کند.

این ویژگی‌ها AI را به ابزاری تبدیل می‌کنند که نه‌تنها فرآیند حل مسئله را تسهیل می‌کند، بلکه می‌تواند جرقه‌ای برای خلاقیت باشد.

آیا AI خلاقیت را تقویت می‌کند؟
استفاده از AI به‌عنوان یک اردک پلاستیکی می‌تواند به دلایل زیر خلاقیت را در مهندسی نرم‌افزار تقویت کند:
1. تشویق به تفکر چندزاویه‌ای
وقتی برنامه‌نویسان مشکل خود را برای AI توضیح می‌دهند، مجبور می‌شوند آن را ساده و ساختارمند بیان کنند، درست مانند تکنیک اردک سنتی. اما پاسخ‌های AI، مانند سؤالات چالش‌برانگیز یا پیشنهادات غیرمنتظره، می‌تواند آن‌ها را به کاوش زوایای جدیدی از مسئله ترغیب کند. این تعامل پویا به ایده‌پردازی خلاقانه کمک می‌کند.

2. کاهش موانع ذهنی
صحبت با یک موجود غیرانسانی، چه اردک پلاستیکی باشد و چه AI، فشار قضاوت را کاهش می‌دهد. برنامه‌نویسان می‌توانند آزادانه ایده‌های خام یا ناقص خود را بیان کنند، بدون ترس از انتقاد. این فضای امن، ذهن را برای نوآوری باز می‌کند.

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

نتیجه‌گیری
هوش مصنوعی، وقتی به‌عنوان یک «اردک پلاستیکی سخنگو» استفاده شود، می‌تواند ابزاری قدرتمند برای تقویت خلاقیت در مهندسی نرم‌افزار باشد. این رویکرد، با ترکیب خود-بازبینی تکنیک اردک سنتی و تعامل پویای AI، به برنامه‌نویسان کمک می‌کند تا مسائل را از زوایای جدید ببینند، ایده‌های نوآورانه تولید کنند و راه‌حل‌های مؤثرتری خلق کنند. بااین‌حال، برای حداکثر اثربخشی، AI باید به‌عنوان یک شریک خلاق عمل کند، نه جایگزینی برای تفکر مستقل.

- انجمن DDD ایران
@DDD_IRAN

اهمیت فزاینده نامگذاری در زمانه‌ی ظهور Vibe Coding

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

زبان فراگیر، به عنوان یکی از ارکان DDD، زبانی مشترک و دقیق است که توسط همه اعضای تیم—از توسعه‌دهندگان و تحلیلگران تا متخصصان دامین—برای توصیف مفاهیم و فرآیندهای دامین استفاده می‌شود. این زبان، با تأکید بر نامگذاری تخصصی و صریح دامین، از ابهام پرهیز می‌کند و تضمین می‌کند که هر مفهوم در کد، مستندات و گفتگوها به شکلی یکنواخت بیان شود. برای مثال، در یک سیستم بانکی، به جای نام مبهم Transaction که می‌تواند معانی متعددی داشته باشد، استفاده از نام‌های دقیق‌تری مانند FundTransfer یا AccountDebit نه تنها برای توسعه‌دهندگان، بلکه برای LLM‌ها نیز درک بهتری از رفتار سیستم فراهم می‌کند.

نامگذاری ضعیف یا مبهم، مانند استفاده از کلمه Record به جای PatientMedicalHistory در یک سیستم پزشکی، می‌تواند LLM‌ها را به تفسیرهای نادرست هدایت کند، زیرا این ابزارها به شدت به کانتکست وابسته‌اند. در مقابل، نامگذاری مبتنی بر زبان فراگیر، کدی تولید می‌کند که مانند متنی خوش‌ساخت، داستان دامین را به شکلی روان روایت می‌کند. این شفافیت، همکاری بین تیم‌های فنی و غیرفنی را تقویت می‌کند و به LLM‌ها امکان می‌دهد پیشنهادات دقیق‌تری ارائه دهند یا اشکالات را سریع‌تر شناسایی کنند.

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

- انجمن DDD ایران
@DDD_IRAN

معرفی Data Mesh: پارادایمی نوین برای مدیریت داده‌ها

شبکه داده (Data Mesh) یک پارادایم نوظهور در مدیریت داده‌ها است که توسط ژامک دهقانی در سال 2019 معرفی شد. این رویکرد به‌منظور رفع چالش‌های مقیاس‌پذیری، پیچیدگی و تمرکززدایی در سازمان‌های داده‌محور طراحی شده است. برخلاف معماری‌های سنتی داده مانند Data Warehouse یا Data Lake که معمولاً متمرکز هستند، Data Mesh بر توزیع مسئولیت‌ها و مالکیت داده‌ها در میان تیم‌های مختلف تأکید دارد. این مدل به‌ویژه برای سازمان‌هایی مناسب است که با حجم عظیمی از داده‌ها و نیاز به چابکی در تحلیل و بهره‌برداری از آن‌ها مواجه هستند.

اصول کلیدی Data Mesh
شبکه داده بر چهار اصل اساسی استوار است:

مالکیت داده‌ها بر اساس دامنه (Domain-Oriented Ownership): به‌جای مدیریت متمرکز داده‌ها توسط یک تیم مرکزی، مسئولیت داده‌ها به تیم‌های مرتبط با دامنه‌های کسب‌وکاری واگذار می‌شود. هر تیم دامنه‌ای، داده‌های خود را به‌عنوان یک محصول مدیریت می‌کند و مسئولیت کیفیت، دسترسی و مستندسازی آن را بر عهده دارد.

داده به‌عنوان محصول (Data as a Product): داده‌ها باید مانند یک محصول تجاری با کیفیت بالا، قابل‌اعتماد و کاربرپسند ارائه شوند. این اصل بر ارائه داده‌ها با مستندات کامل، رابط‌های استاندارد و قابلیت کشف‌پذیری تأکید دارد.

زیرساخت خودخدمت (Self-Serve Data Platform): برای پشتیبانی از تیم‌های دامنه‌ای، یک پلتفرم داده‌ای خودخدمت ارائه می‌شود که ابزارها و قابلیت‌هایی مانند پردازش داده، ذخیره‌سازی و تحلیل را در اختیار تیم‌ها قرار می‌دهد. این پلتفرم امکان استقلال تیم‌ها را فراهم می‌کند.

حاکمیت فدرال (Federated Governance): به‌جای حاکمیت متمرکز، Data Mesh از یک مدل حاکمیتی فدرال استفاده می‌کند که در آن استانداردهای مشترک (مانند فرمت داده، امنیت و انطباق) توسط تیم‌های دامنه‌ای و با همکاری یک تیم حاکمیتی مرکزی تعریف می‌شود.


مزایای Data Mesh

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

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

نتیجه‌گیری
شبکه داده یک تحول اساسی در مدیریت داده‌ها ارائه می‌دهد که با نیازهای سازمان‌های مدرن هم‌خوانی دارد. با تمرکز بر توزیع مالکیت، محصول‌محوری داده‌ها و زیرساخت‌های خودخدمت، این پارادایم به سازمان‌ها کمک می‌کند تا داده‌های خود را به‌صورت مؤثرتر و چابک‌تر مدیریت کنند. اگرچه پیاده‌سازی آن نیازمند تلاش و هماهنگی است، اما مزایای بلندمدت آن در مقیاس‌پذیری و نوآوری داده‌محور، Data Mesh را به گزینه‌ای جذاب برای سازمان‌های داده‌محور تبدیل کرده است.

اطلاعات بیشتر:
https://youtu.be/CDWp_xyCdzw?si=ec_WmBXWTNeqSFcq
- انجمن DDD ایران
@DDD_IRAN

آیا نوشتن تست خودکار با ظهور هوش مصنوعی کار مقرون به صرفه‌ای است؟

با پیشرفت هوش مصنوعی (AI) در توسعه نرم‌افزار، نوشتن تست‌های خودکار به روش سنتی در برخی موارد و به دلایل زیر می‌تواند مقرون به صرفه نباشد. این موضوع به دلیل توانایی هوش مصنوعی در تولید خودکار کد و تست، تغییر چرخه توسعه نرم‌افزار، و کاهش هزینه‌های نگهداری تست‌ها است.

۱. تولید خودکار کدها و تست‌ها
ابزارهای هوش مصنوعی، مانند مدل‌های زبانی پیشرفته، می‌توانند کد و تست‌های خودکار را به‌سرعت تولید کنند. برای مثال، برای یک تابع ساده، هوش مصنوعی نه تنها کد را می‌نویسد، بلکه تست‌های واحد و لبه‌ای را نیز ایجاد می‌کند. این قابلیت زمان و تلاش مورد نیاز برای نوشتن دستی تست‌ها را به شدت کاهش می‌دهد. در نتیجه، صرف زمان برای توسعه تست‌های سنتی کمتر توجیه‌پذیر است، زیرا هوش مصنوعی همان کار را با سرعت و دقت بیشتری انجام می‌دهد.

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

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

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

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

-انجمن DDD ایران
@DDD_IRAN

چرا تکنیک Event Storming با تأکید بر Eventها شروع می‌شود؟

تکنیک Event Storming یکی از تکنیک‌های موثری است که برای مدل‌سازی فرآیندهای کسب‌وکار و کشف دامنه‌های پیچیده به کار می‌رود. این روش با تأکید بر شناسایی Eventها (رویدادها) به‌عنوان نقطه شروع فرآیند مدل‌سازی آغاز می‌شود. اما چرا Eventها در این تکنیک نقش محوری دارند و چرا باید ابتدا آن‌ها را شناسایی کنیم؟

۱. تمرکز بر رفتار دامنه
رویدادها نشان‌دهنده اتفاقات معناداری هستند که در دامنه کسب‌وکار رخ می‌دهند، مانند «سفارش ثبت شد»، «پرداخت انجام شد» یا «محصول به انبار اضافه شد». این رویدادها نقاط عطف فرآیندها و تغییرات حالت در سیستم را مشخص می‌کنند. با شروع از Eventها، تیم مدل‌سازی به‌جای تمرکز بر ساختارهای داده‌ای یا موجودیت‌ها، ابتدا بر رفتار سیستم تمرکز می‌کند. این رویکرد رفتارمحور (Behavior-Driven) به درک عمیق‌تر و واقعی‌تر از چگونگی عملکرد دامنه کمک می‌کند و از پیچیدگی‌های غیرضروری در مراحل اولیه جلوگیری می‌نماید.

۲. ایجاد زبان مشترک
یکی از اهداف کلیدی در DDD، ایجاد زبان مشترک (Ubiquitous Language) بین ذی‌نفعان مختلف، از جمله توسعه‌دهندگان، کارشناسان کسب‌وکار و مدیران است. Eventها به دلیل ماهیت ساده و ملموسشان، به‌عنوان ابزاری برای برقراری این زبان مشترک عمل می‌کنند. برای مثال، عبارتی مانند «سفارش لغو شد» برای همه قابل‌فهم است و نیازی به دانش فنی ندارد. شروع با شناسایی Eventها به تیم کمک می‌کند تا روی توصیفات مشترک و قابل‌فهم توافق کنند و از سوءتفاهم‌های ناشی از اصطلاحات تخصصی جلوگیری شود.

۳. بازسازی جریان فرآیند
رویدادها نقاط کلیدی در جریان فرآیندهای کسب‌وکار را نشان می‌دهند. با قرار دادن Eventها به ترتیب زمانی روی یک خط زمان، می‌توان به‌راحتی کل فرآیند را بازسازی کرد. این کار نه‌تنها به درک بهتر توالی وقایع کمک می‌کند، بلکه گپ‌ها، ابهامات یا ناسازگاری‌های موجود در فرآیند را نیز آشکار می‌سازد. برای مثال، ممکن است تیم متوجه شود که بین «سفارش ثبت شد» و «پرداخت انجام شد» مرحله‌ای گم شده است، که این کشف به بهبود مدل دامنه منجر می‌شود.

۴. کاهش پیچیدگی در مدل‌سازی
تمرکز اولیه بر موجودیت‌ها (Entities) یا ساختارهای داده‌ای می‌تواند تیم را درگیر جزئیات فنی و پیچیدگی‌های زودهنگام کند. در مقابل، Eventها معمولاً ساده‌تر و قابل‌فهم‌تر هستند. شروع با Eventها به تیم اجازه می‌دهد بدون غرق شدن در پیچیدگی‌های فنی، ابتدا روی چیستی دامنه و اتفاقات مهم آن تمرکز کند. این رویکرد تدریجی، فرآیند مدل‌سازی را روان‌تر و مؤثرتر می‌کند.

۵. تسهیل کشف Commandها و Aggregateها
رویدادها به‌ عنوان خروجی‌های فرآیندها، سرنخ‌هایی برای شناسایی Commandها (دستورات) و Aggregateها ارائه می‌دهند. برای مثال، Event «سفارش ثبت شد» می‌تواند به Command «ثبت سفارش» و Aggregate «سفارش» اشاره داشته باشد. با شناسایی Eventها در ابتدا، تیم می‌تواند به‌صورت طبیعی و منطقی به سمت کشف سایر اجزای مدل دامنه، مانند Commandها، Aggregateها و قوانین کسب‌وکار حرکت کند. این فرآیند گام‌به‌گام به ایجاد مدلی دقیق و منسجم منجر می‌شود.

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

-انجمن DDD ایران
@DDD_IRAN

در زمانه‌ای که تیترهای پر زرق‌و‌برق هوش مصنوعی فریاد می‌زنند «بدون کدنویسی اپلیکیشن ساختم!»، این مطلب خواندنی از Vlad Khononov ما یادآوری می‌کند که چرا «ماژولاریتی» اهمیت فزاینده‌ای پیدا کرده و چگونه می‌تواند در این زمانه به ابزارهای کدنویسی با کمک هوش مصنوعی کمک کند. این نوشته مفهوم مدولاریتی را از دهه ۶۰ میلادی تا امروز دنبال می‌کند و نشان می‌دهد چرا در عصر مدل‌های زبانی بزرگ (LLMها)، طراحی ماژولار نه فقط یک انتخاب، بلکه یک ضرورت است.

ماژولاریتی چیست؟ سیستمی که تغییرش آسان باشد: بدانید چه بخش‌هایی را باید تغییر دهید و پیش‌بینی کنید تغییر چه اثری خواهد داشت. در مقابل، پیچیدگی مانند بمبی ساعتی است که نمی‌دانید با دستکاری‌اش چه انفجاری رخ می‌دهد. این مقاله با مثال‌هایی ملموس، از بار شناختی انسان تا محدودیت‌های context window در LLMها، توضیح می‌دهد که چرا ماژولها در طراحی سیستم‌ها حیاتی‌تر از گذشته شده‌اند.

The Golden Age of Modularity
https://www.linkedin.com/pulse/golden-age-modularity-vlad-khononov-swjbf

توسعه نرم‌افزار: یک فعالیت اجتماعی-فنی

توسعه نرم‌افزار فراتر از نوشتن کد و طراحی سیستم‌هاست؛ این فرآیند به‌عنوان یک فعالیت اجتماعی-فنی (Socio-Technical) شناخته می‌شود که در آن عوامل انسانی و فنی به‌طور جدایی‌ناپذیری درهم‌تنیده‌اند. موفقیت یک پروژه نرم‌افزاری نه‌تنها به فناوری‌های پیشرفته، بلکه به همکاری تیمی، ارتباطات شفاف و فرهنگ سازمانی نیز وابسته است.

چرا توسعه نرم‌افزار یک فعالیت اجتماعی-فنی است؟

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

در مقابل، بعد فنی شامل ابزارها، معماری سیستم و کیفیت کد است. انتخاب فناوری مناسب، طراحی سیستم‌های مقیاس‌پذیر و استفاده از فرآیندهای خودکار مانند CI/CD برای اطمینان از کارایی و قابلیت نگهداری حیاتی هستند. با این حال، این دو بعد به‌طور مداوم بر یکدیگر تأثیر می‌گذارند. تصمیمات فنی ممکن است تحت تأثیر ترجیحات تیمی یا فشارهای سازمانی قرار گیرند، و مشکلات ارتباطی می‌توانند به بدهی فنی منجر شوند.

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

پیامدهای اجتماعی-فنی بودن

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

🔹 دوم، روش‌های چابک مانند اسکرام یا کانبان برای هماهنگی جنبه‌های اجتماعی و فنی طراحی شده‌اند. جلسات روزانه، بازخورد مستمر و همکاری نزدیک با ذی‌نفعان به تیم‌ها کمک می‌کند تا با تغییرات سازگار شوند.

🔹 سوم، ابزارها و فرآیندها باید تعاملات انسانی را تسهیل کنند. برای مثال، ابزارهایی مانند GitHub یا Slack همکاری را بهبود می‌بخشند، اما انتخاب ابزار نامناسب می‌تواند ارتباطات را مختل کند.

🔹 چهارم، سازمان‌ها باید بدهی فنی (مشکلات در کد) و بدهی اجتماعی (مشکلات در اعتماد یا ارتباطات) را مدیریت کنند. نادیده گرفتن بدهی اجتماعی می‌تواند به کاهش انگیزه یا تعارض منجر شود، در حالی که بدهی فنی هزینه‌های نگهداری را افزایش می‌دهد. در نهایت، ایجاد فرهنگ یادگیری که اشتباهات را فرصتی برای رشد بداند، برای نوآوری و کیفیت ضروری است.

جمع‌بندی

توسعه نرم‌افزار به دلیل نیاز به همکاری انسانی و فناوری پیشرفته، یک فعالیت اجتماعی-فنی است. این ماهیت ایجاب می‌کند که سازمان‌ها در کنار ابزارهای فنی، روی مهارت‌های تیمی، فرآیندهای چابک و فرهنگ مثبت سرمایه‌گذاری کنند. نادیده گرفتن هر یک از این جنبه‌ها می‌تواند به شکست پروژه منجر شود، اما توجه به آن‌ها می‌تواند به تولید نرم‌افزارهایی با کیفیت و تأثیرگذار منجر گردد.

- انجمن DDD ایران
@DDD_IRAN

هم‌افزایی ایده‌های مطرح در Team Topologies و Domain-Driven Design

در دنیای توسعه نرم‌افزار، هم‌راستایی و تناسب ساختار تیم‌ها با معماری سیستم و اهداف کسب‌وکار برای تحویل سریع و مؤثر ارزش به مشتری حیاتی است. رویکرد Domain-Driven Design و چارچوب Team Topologies دو رویکرد مکمل هستند که این هم‌راستایی را تسهیل می‌کنند. اما چرا تیم‌های جریان ارزش (Stream-Aligned Teams) در Team Topologies با Bounded Context ها در DDD هم‌راستا می‌شوند؟!

در DDD، مفهوم B.C یک مفهوم کلیدی است که بخشی مشخص از دامنه کسب‌وکار را با مدلی خاص، زبان فراگیر (Ubiquitous Language)، و قوانین داخلی خود تعریف می‌کند. هر B.C به‌گونه‌ای طراحی می‌شود که مستقل باشد و از طریق رابط‌های مشخص، مانند APIها یا رویدادها، با سایر B.C ها تعامل کند. برای مثال، در یک سیستم تجارت الکترونیک، مدیریت موجودی و پردازش سفارشات ممکن است به‌عنوان دو B.C جداگانه تعریف شوند، هرکدام با مفاهیم و قوانین خاص خود.

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

▫️ تیم‌های جریان ارزش در Team Topologies
چارچوب Team Topologies، ارائه‌شده توسط متیو اسکلتون و مانوئل پایس، چهار نوع تیم را معرفی می‌کند: تیم‌های جریان ارزش (Stream-Aligned Teams)، تیم‌های توانمندساز (Enabling)، تیم‌های پلتفرم (Platform)، و تیم‌های مختص به زیرسیستم‌های پیچیده (Complicated Subsystem).
تیم‌های جریان ارزش مسئول تحویل مستمر ارزش به مشتری یا کاربر نهایی هستند. این تیم‌ها بر یک جریان ارزش مشخص، مانند یک محصول، سرویس، یا تجربه کاربری، تمرکز دارند و از ابتدا تا انتها مسئول آن هستند.

تیم‌های جریان ارزش برای چابکی و پاسخ‌گویی به نیازهای مشتری طراحی شده‌اند. آن‌ها خودمختار هستند، اما برای تحویل ارزش به همکاری با سایر تیم‌ها، مانند تیم‌های پلتفرم برای زیرساخت یا تیم‌های توانمندساز برای ابزارها، وابسته‌اند. تعاملات این تیم‌ها بر اساس سه مدل تعریف می‌شود: همکاری، خدمت‌رسانی (X-as-a-Service)، و تسهیل‌گری.

▫️چرا ایده تیم‌های جریان ارزش با مفهوم B.C هم راستا است؟
هم‌راستایی تیم‌های جریان ارزش با مفهوم B.C به دلایل زیر منطقی و مؤثر است:

🔹تمرکز بر دامنه مشخص: B.C در DDD به تیم‌ها اجازه می‌دهند تا روی یک بخش مشخص از دامنه کسب‌وکار تمرکز کنند. این تمرکز با هدف تیم‌های جریان ارزش، که تحویل ارزش به مشتری در یک جریان مشخص است، هم‌خوانی دارد. برای مثال، یک تیم جریان ارزش که مسئول تجربه خرید مشتری است، می‌تواند با B.C پردازش سفارشات هم‌راستا شود تا مدل‌های دامنه‌ای مرتبط با سبد خرید و پرداخت را توسعه دهد.

🔹خودمختاری و کاهش وابستگی‌ها: B.C به‌گونه‌ای طراحی شده‌اند که وابستگی‌های بین زیرسیستم‌ها را از طریق رابط‌های مشخص، مانند APIها یا رویدادها، به حداقل برسانند. این استقلال با ایده خودمختاری تیم‌های جریان ارزش هم‌راستاست، زیرا این تیم‌ها می‌توانند به‌صورت مستقل ویژگی‌های جدید را توسعه داده و مستقر کنند، بدون نیاز به هماهنگی گسترده با سایر تیم‌ها. Team Topologies نیز با محدود کردن تعاملات غیرضروری، این خودمختاری را تقویت می‌کند.

🔹انطباق با قانون کانوی: قانون کانوی بیان می‌کند که معماری سیستم‌ها بازتاب ساختار سازمانی تیم‌هاست. هم‌راستایی تیم‌های جریان ارزش با زمینه‌های محدود تضمین می‌کند که ساختار تیم‌ها با معماری سیستم هم‌خوان باشد. این انطباق باعث می‌شود که سیستم‌های نرم‌افزاری منعکس‌کننده مرزهای دامنه باشند و پیچیدگی‌های ارتباطی کاهش یابد.

🔸نتیجه‌گیری
هم‌راستایی تیم‌های جریان ارزش با مفهوم B.C در DDD به دلیل تمرکز مشترک آن‌ها بر دامنه مشخص، خودمختاری، و انطباق با قانون کانوی منطقی است. این هم‌راستایی، همراه با تمرکز تیم‌های جریان ارزش بر تحویل ارزش به مشتری، امکان توسعه سریع و مؤثر ویژگی‌هایی را فراهم می‌کند که نیازهای کسب‌وکار و مشتری را برآورده می‌سازند. ترکیب راهنماهای طراحی در DDD و Team Topologies به تیم‌ها کمک می‌کند تا سیستم‌های مقیاس‌پذیر و مشتری‌محور ایجاد کنند. فرهنگ همکاری و ارتباطات شفاف، کلید موفقیت این هم‌افزایی است.

- انجمن DDD ایران
@DDD_IRAN

🔍 معرفی مختصر Exploratory Domain Discovery (EDD)

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

این رویکرد، ریشه در تفکر سیستماتیک و روایت‌محور دارد. درست مثل یک فیلم یا رمان که همه‌ی اتفاقات برای انتقال یک پیام اصلی طراحی شده‌اند، در دامنه‌ی یک نرم‌افزار هم بیشتر اجزای سیستم در خدمت یک «مفهوم کلیدی» یا همان Main Point هستند؛ چیزی که بدون آن، کل ساختار بی‌معنا می‌شود. در EDD ما تلاش می‌کنیم این نقطه‌ی مرکزی را پیدا کرده و روابط علّی و ساختارهای اطراف آن را کشف کنیم.

🌀 فرآیند اکتشاف در EDD به‌صورت چرخشی (Iterative) و عرضی (Breadth-First) انجام می‌شود. فرض کنید Main Point در مرکز یک‌سری دایره‌ی هم‌مرکز قرار دارد. در دور اول، تصویری کلی و انتزاعی از دامنه ساخته می‌شود. در دورهای بعدی، این دایره تنگ‌تر شده و وارد جزئیات بیشتری می‌شویم. این مدل‌سازی لایه‌لایه، کمک می‌کند پیچیدگی‌ها را بهتر درک کرده و رفتارهای تکرارشونده را بشناسیم.

✨ یکی از ویژگی‌های کلیدی EDD، روایت معکوس (Backward Storytelling) است — یعنی به‌جای اینکه با «از کجا شروع کنیم؟» آغاز کنیم، می‌پرسیم: «ته داستان چیست؟». این دیدگاه باعث می‌شود روابط علت و معلولی واضح‌تر و دقیق‌تر دیده شوند.


🧩 در EDD ما با سه ابزار اصلی کار می‌کنیم:

🟦 مفهوم Domain Concept: هر مفهوم کلیدی که در دامنه وجود دارد را روی یک کارت می‌نویسیم.

🔄 مفهوم Relation : رابطه‌ی بین این مفاهیم را مشخص می‌کنیم، از انتها به ابتدا.

📝 مفهوم Example : برای هر مفهوم، یک نمونه واقعی و قابل لمس می‌نویسیم تا فهم مشترک بین افراد تیم شکل بگیرد.

🎯 مثال کاربردی:

فرض کنید در حال تحلیل یک سیستم حقوق و دستمزد هستید.
از سؤال «ته داستان چیست؟» شروع می‌کنیم: مثلاً صدور فیش حقوقی خروجی نهایی است. آن را روی یک کارت مفهومی (domain concept) یادداشت می‌کنیم. سپس یک گام به عقب: فیش حقوقی حاصل محاسبه‌ی فرمول‌های حقوق است. این فرمول‌ها هم بر اساس کارکرد ماهانه‌ی کارمند محاسبه می‌شوند.
با همین روال، مفاهیم را از پایان به ابتدا کشف و یادداشت می‌کنیم. سپس روابط میان آن‌ها را (باز هم از انتها به ابتدا) ثبت می‌کنیم. در پایان، برای هر مفهوم یک مثال واقعی (concrete example) می‌نویسیم تا از درستی و شفافیت مدل اطمینان حاصل شود.

🧠 فلسفه‌ی EDD:

• بهره‌گیری از تفکر سیستماتیک و روایت‌محور
• تمرکز بر کشف تدریجی و دید کل‌نگر به دامنه
• مدل‌سازی چرخشی برای کشف رفتارهای تکرارشونده دامنه

🔁 الگوهای رایج (Patterns):

• چرخه‌های زمانی مثل حقوق ماهیانه یا فرایند رزرو
• مفهوم کلیدی (Main Point) که سایر اجزای دامنه حول آن شکل می‌گیرند
• روایت معکوس برای کشف روابط علت و معلولی

✅ در نهایت اینکه:
EDD ابزارهای ساده‌ای داره — مثل کارت‌های مفهومی و مثال — اما قدرتش در طرز فکر پشتشه: اینکه قبل از ورود به طراحی یا کدنویسی، دقیقاً بفهمیم چه چیزی را طراحی می‌کنیم و چرا.

📎 اطلاعات بیشتر:
https://exploratorydomaindiscovery.com

-انجمن DDD ایران
@DDD_Iran