https://virgool.io/feed/@msavarian software architecture/developer fa 2026-06-10 15:11:25 https://files.virgool.io/upload/users/71685/avatar/Ijm7vV.jpg?height=120&width=120 https://virgool.io/@msavarian https://virgool.io/@msavarian/domain-storytelling-%D8%B1%D8%A7%D9%87%DA%A9%D8%A7%D8%B1-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D9%88-%D8%AA%D8%B9%D8%A7%D9%85%D9%84-%D9%85%D9%88%D8%AB%D8%B1-%D8%AF%D8%B1-ddd-u3jraqyuocdh زمانی که ما شروع به پیاده سازی یک سیستم نرم افزاری میکنیم به این معنی است که احتمالا فضای مسئله (Problem Space) را درک کرده ایم و به طراحی یک مدل برای فضای راه حل (Solution Space) مشغول هستیم.اغلب چنین اتفاقی نمی افتد و معمولا حتی در زمانی که به عنوان یک مهندس نرم افزار در حال طراحی و پیاده سازی سیستم هستیم باز هم درک درستی از نیاز و مسئله یا شیوه انجام کار در فضای کسب و کار نداریم که معمولا ناشی از موارد زیر می باشد :سوتفاهم ها و ناهمانگی های موجود بین تیم ها و افراد مرتبط شامل کارشناسان دامنه (Business/Domain Experts، Product Managers/Owners) و تیم توسعه (Software Engineers/Developers)نبود مستندات یا توضیحات کافی از نیازمندی های سیستمعدم شفافیت در مسئله و متعاقبا عدم شناسایی دقیق روال های فعلی کسب و کارضعف در زبان مشترکو ...همه موارد فوق نهایتا منجر به درک متفاوت و اشتباه از فضای کسب و کار و ارائه یک راه حل اشتباه و در نهایت یک نرم افزار ناکارآمد خواهد شد.همچنین گاها موجب عدم نمایان شدن اختلاف نظر بین افراد حاضر در تیم کارشناسان دامنه و تیم توسعه می شود تا زمانی که یک نسخه از محصول دریافت می کنند و این چرخه تا زمانی که درک درستی از فضای کسب و کار پیدا شود ادامه پیدا میکند.It’s developer’s (mis)understanding, not expert knowledge that gets released into production.Alberto BrandoliniEvent Storming Authorکشف دامنه (Domain Discovery)کشف دامنه یا همان Domain Discovery به فرآیند شناسایی و درک نسبتا عمیق دامنه کسب و کار، شناسایی مفاهیم کلیدی در روال ها، رویدادها و همچنین روابط بین آنها می پردازد.ابزارها و تکنیک های مختلفی برای این کار تا به امروز معرفی شده اند شامل : Event StormingContext MappingDomain StorytellingService BlueprintingImpact Mapping... .داستان سرایی دامنه (Domain Storytelling)در تکنیک Domain Storytelling کارشناسان دامنه و کاربران، تجربیات خود را به شکل داستان و به صورت تعاملی بیان میکنند تا افراد حاضر در تیم ها به درک بهتری از فضای کسب و کار و نیازمندی ها، دست پیدا کنند.تکنیک Domain storytelling در سال 2018 توسط آقای استفان هوفر و آقای هنینگ شوونتنر معرفی شده است.استفاده از این تکنیک به صورت مکمل برای سایر تکنیک ها مثل Event Storming نهایتا می تواند منجر به یک مدل سازی بهتر می شود.توضیحات کاملی این تکنیک در سایت domainstorytelling.org و کتاب Domain Storytelling A Collaborative, Visual, and Agile Way to Build Domain-Driven Software که در سال 2021 منتشر شد، وجود دارد که می توانید به آنها رجوع کنید.در ادامه مقاله به شکلی مختصر به ابعاد مختلف این تکنیک و نحوه برگزاری جلسه و مدل سازی آن پرداخته ام اما قبل از آن خوب است که مختصری از ارتباط این روش با روش Event Storming رو بررسی کنیم.تکنیک Domain storytelling به عنوان مکمل روش Event Stormingهمان طور که پیش تر گفته شد در Domain Storytelling تمرکز بر روایت داستان ها و تجربیات کاربران است ولی در Event Storming تمرکز بر شناسایی رویدادهای کلیدی دامنه (Events) و ترتیب زمانی آنها است.می توان به شکلی Domain Storytelling را به عنوان یک مرحله پیش نیاز برای Event Storming در نظر گرفت، چرا که در Storytelling افراد با به یک مدل کلی از فرآیندها آشنا می شوند و در این حین با نقش ها و زبان دامنه (Ubiquitous Language) نیز آشنا می شوند، سپس در Event Storming با توجه به دانش نسبی که نسبت به این فرآیند های کسب و کار، زبان دامنه و نقش ها در جلسات Storytelling دست پیدا کرده اند، اکنون به شکل بهتر و سریع تری می توانند رویدادهای دامنه (Events)، Commandها و موجودیت ها را از طریق جلسات Event Storming شناسایی کنند.همچنین تجربه نشان داده است که یک قصه گوی خوب در جلسات Event Storming می تواند به بهبود ارتباط بین اعضای تیم کمک کند و نسبت به ایجاد زبان فراگیر (Ubiquitous Language) قوی کمک کند، همچنین در صورتی که داستان ها به خوبی بیان شوند بخش های پر چالش در کسب و کار که نیاز به تمرکز بیشتری دارند نیز به شکل ساده تری مشخص می شوند.نتیجه گیریاستفاده از تکنیک Domain Storytelling در درک و شناخت مسئله با استفاده از بیان تجربیات به شکل قصه گویی و همچنین ساختن یک زبان فراگیر (Ubiquitous Language) بین افراد تیم توسعه و کارشناسان دامنه (Domain Experts) و همچنین افزایش و بهبود تعامل بین این افراد کمک میکند.ادامه...در بخش های بعدی این مقاله به ترتیب فرآیند و نحوه برگزاری جلسات Domain Storytelling و Event Storming رو بررسی خواهیم کرد. محمود سواریان محمود سواریان Wed, 17 Jul 2024 14:48:30 +0330 https://virgool.io/@msavarian/%D9%85%D8%B3%D8%AA%D9%86%D8%AF-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-ezy9y4kvditm در قسمت اول این مقاله ، مشخصات کلیدی یک سرویس مورد بررسی قرار گرفت و  API‌ها و وابستگی‌ها یا Dependencies هر سرویس نیز مورد بررسی قرار گرفتند. همانطور که مشخص است با زیاد شدن این سرویس‌ها و وابستگی هایی که به یکدیگر پیدا میکنند، سردرگمی‌ها نیز برای اعضای تیم‌های مختلف، زیاد میگردد. چرا که افراد هر تیم دائما باید از API‌های ارائه شده توسط تیم‌های دیگر مطلع باشند. به همین جهت زمانیکه شما یک سبک معماری مانند میکروسرویس را انتخاب می‌نمایید، باید یک روش مستند سازی مناسب را نیز انتخاب نمایید تا مانع از پیچیدگی و سردرگمی ناشی از نبود مستندات مناسب و سربار هماهنگی بین تیمی شوید.در این مطلب، 2 روش زیر، جهت مستند سازی سرویس‌ها بررسی می‌شوند:روش اول - کارت طراحی میکروسرویس (microservice design card)روش دوم - بوم میکروسرویس (microservice canvas)لازم به ذکر است که دو روش فوق می‌توانند مکمل یکدیگر باشند؛ همچنین این اسناد (علاوه بر مفید بودن برای مصرف کنندگان سرویس) حتی جهت شناسایی سرویس‌ها و ارتباطات بین آنها در زمان تحلیل (در جلساتی مانند event storming) نیز می‌توانند کاربردی باشند.روش اول - کارت طراحی میکروسرویس (microservice design card)روش کارت طراحی میکروسرویس بر اساس کارت‌های CRC که گاهی اوقات در Object-oriented design استفاده می‌شوند، مدل سازی شده‌است و می‌توان از آن جهت ثبت خدمات سرویس و همچنین تعاملات سرویس، با سایر سرویس ها، استفاده نمود (این اطلاعات نسبت به اطلاعات قابل درج در microservice canvas که در ادامه بررسی می‌شود، کمتر است).می‌توانید این کارت‌ها را در ابعاد کوچک و به تعداد کافی پرینت و در هنگام تحلیل و طراحی سرویس(ها)، از آنها استفاده نماییددر نهایت جهت کشیدن نقشه وابستگی سرویس‌ها، کارت‌ها روی یک برد نصب و با کشیدن خطوط بین سرویس‌ها، وابستگی‌های هر یک را مشخص نمایید. مزیت اصلی این روش در طراحی، همکاری بیشتر تیم‌ها با یکدیگر می‌باشد.(نمونه ای از کارت طراحی ‌های مربوط سرویس‌های project و archive)روش دوم - بوم میکروسرویس (microservice canvas) یکی دیگر از روش‌های مناسب برای مستند سازی یک سرویس و ساختار درونی آن، استفاده از روش بوم میکروسرویس می‌باشد. بوم میکروسرویس نیز تا حدودی شبیه به کارت‌های CRC و همچنین روش microservice design card که پیش‌تر بررسی گردید، می‌باشد؛ با این تفاوت که اطلاعات بیشتری را نگهداری می‌نماید.روش طراحی روی بوم جهت مستند سازی، از گذشته در صنایع مختلفی از جمله صنعت نرم افزار رایج بوده است؛ ولی ظاهرا برای اولین بار در سال 2017 و در این مقاله  (از سایت DZone که توسط Matt McLarty و Irakli Nadareishvili منتشر شده‌است) از این روش به عنوان روشی برای مستند سازی سرویس‌ها (در معماری میکروسرویس) استفاده شده‌است . پس از آن و در طول زمان، نمونه‌های مختلف و نسبتا مشابهی از این بوم توسط افراد و شرکت‌های مختلف ارائه شد (که با جستجوی عبارت microservice canvas در بخش تصاویر سایت گوگل می‌توانید نمونه‌های متفاوت آن را بررسی نمایید). در ادامه این مقاله، بوم میکروسرویسی که آقای ریچاردسون در سال 2019 معرفی نمودند، بررسی می‌گردد.تصویر فوق بوم مربوط به سرویس Order می‌باشد با توجه به تصویر فوق و مفاهیم بررسی شده در قسمت قبلی این مقاله، به بررسی بخش‌های مختلف بوم میکروسرویس می‌پردازیم.نمای بیرونی یک سرویس (A service’s external view) در بوم میکروسرویس توسط بخش‌های زیر معرفی می‌گردد• Name – نام سرویس • Description – ارائه یک توضیح مختصر در مورد سرویس • Capabilities – معرفی بخش‌هایی از منطق کسب و کار که در این سرویس پیاده سازی شده‌است. • Service APIs – معرفی عملیات یا operations (شامل commands  و queries) که در این سرویس پیاده سازی شده‌اند و همچنین معرفی وقایع یا همان domain event هایی که توسط سرویس منتشر می‌شوند. • Quality attributes – معرفی non-functional requirements‌های سرویس • Observability (قابلیت‌های مشاهده و بررسی  سرویس) – معرفی health check endpoints و key metrics و ... .وابستگی‌های یک سرویس (A service’s dependencies)  که لزوما استفاده بیرونی ندارد و بیشتر منبعی برای خود اعضای تیم خواهد بود، در بخشی تحت عنوان dependencies مشخص می‌شوند که خود شامل دو قسمت به شرح زیر می‌باشد:• Invokes – عملیاتی که در سایر سرویس‌ها پیاده سازی شده‌اند و در این سرویس فراخوانی می‌گردند. • Subscribes – اشتراک در کانال پیام‌هایی که شامل وقایع سایر سرویس‌ها می‌باشند.موارد مربوط به پیاده سازی یک سرویس (A service’s implementation)در بوم میکروسرویس علاوه بر تمام موارد فوق، شما میتوانید مدل پیاده سازی لایه دامنه را نیز معرفی نمایید. همچنین نام bounded context‌ها و aggregateهای پیاده سازی شده در این سرویس، در این بخش نوشته می‌شود (که در یک حالت ایده آل، تنها یک agg از یک bc در یک سرویس پیاده سازی خواهد شد).تولید بوم میکروسرویسبا توجه به دغدغه ناشی از به روز نگه داشتن بوم میکروسرویس (و به طور کلی مستندات پروژه) همراه با تغییرات پروژه، تکنیک‌ها و ابزارهایی جهت تولید خودکار فایل json بوم میکروسرویس (microservice-canvas-tools) و همچنین جهت به تصویر کشیدن فایل json تولید شده (microservices-design-canvas-editor ) وجود دارد. اما اگر ابزار مناسبی را با توجه به پلتفرم مورد نظر، نتواستید پیدا کنید و یا فرصت توسعه یک ابزار اختصاصی نبود، همواره می‌توان این فایل را به صورت دستی نیز ایجاد نمود و در مخزن کد مربوط به پروژه و در کنار سورس اصلی نگه داری کرد تا همراه با سایر مستندات پروژه، این سند نیز پس از هر تغییر به روز شود. نسخه‌ای از آن را نیز می‌توان در محلی مناسب با سایر تیم‌ها به اشتراک گذاشت.در صورتیکه قصد تولید و توسعه دستی این سند را دارید، نسخه‌ای از آن را در قالب فایل ورد، می‌توانید در این مخزن در گیت هاب پیدا نمایید. محمود سواریان محمود سواریان Fri, 18 Dec 2020 21:24:06 +0330 https://virgool.io/@msavarian/%D9%85%D8%B3%D8%AA%D9%86%D8%AF-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%85%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-mvia0sgliwas معماری میکروسرویس (یا به اختصار: میکروسرویس) یک سبک معماری نرم افزار می‌باشد که در آن یک نرم افزار، به مجموعه‌ای از سرویس‌ها خرد می‌شود؛ به نحوی که هر سرویس مسئولیت انجام بخشی از منطق کسب و کار را به عهده داشته باشد. این تقسیم بندی مزایای متعددی را به همراه دارد که نهایتا پیاده سازی و توسعه راحت‌تر نرم افزار‌های بزرگ و پیچیده را ممکن می‌نماید. از جمله مزایای این معماری می‌توان به راحت‌تر شدن مباحث continuous delivery/deployment، مقیاس پذیری بهتر، تحمل خطا، مهاجرت به (و یا استفاده از) تکنولوژی‌های جدید در بخش‌های مختلف نرم افزار و ... اشاره نمود. مهم‌ترین بخش و تصمیمات شما به عنوان یک معمار نرم افزار، هنگام طراحی با استفاده از این معماری، شناسایی بخش‌های مختلف کسب و کار، جدا سازی و مرزبندی نمودن آنها و نهایتا طراحی سرویس‌ها و تعیین نحوه همکاری آنها با یکدیگر می‌باشد. لذا در هنگام استفاده از معماری میکروسرویس، مرکز توجهات باید کسب و کار باشد و نه مسائل تکنیکال و موضوعاتی مانند Docker, Kubernetes , Serverless و ... . (DDD می‌تواند به شما جهت مرزبندی بخش‌های مختلف کسب و کار و شناسایی سرویس‌ها کمک نماید) تا اینجا متوجه شدیم که میکروسرویس در واقع یک سبک معماری نرم افزار محسوب می‌گردد و در واقع میکروسرویس (در اینجا و ادامه مقاله، منظور از میکروسرویس، معماری میکروسرویس می‌باشد) از چندین سرویس مجزا و مستقل تشکیل شده‌است که هر سرویس معمولا مسئولیت بخشی از منطق کسب و کار را بر عهده خواهد داشت.مشخصات یک سرویسهر سرویس در معماری میکروسرویس دارای چندین ویژگی اصلی به شرح زیر می‌باشد:- Loosely coupled with other services - باید به طور مستقل از سایر سرویس‌ها عمل کند. به این معنا که تغییر و توسعه سایر سرویس‌ها موجب اختلالی در عملکرد این سرویس نگردد و برعکس، تغییر و توسعه این سرویس نباید عملکرد سایر سرویس‌ها را مختل نماید.- Independently deployable - تیم توسعه دهنده سرویس قادر باشد تا بدون نیاز به هماهنگی با سایر تیم‌ها، خدمات خود (شامل ویژگی‌های جدید و تغییرات) را مستقر (Deploy) نماید.- Capable of being developed by a small team – سرویس، امکان توسعه توسط یک تیم کوچک را داشته باشد. این مورد به جهت جلوگیری از سربار زیاد ناشی از هماهنگی در تیم‌های بزرگ، ضرورت دارد.- Highly maintainable and testable – سرویس بسیار قابل نگهداری و قابل آزمایش باشد؛ امکان توسعه، تست و استقرار سریع را داشته باشد.ساختار یک سرویسحال که با ویژگی‌ها و مشخصات اصلی یک سرویس آشنا شدیم، در دیاگرام زیر، ساختار درونی یک سرویس را که از معماری هگزاگون (hexagonal architecture) استفاده می‌نماید، بررسی میکنیم. در این معماری، هسته سرویس، منطق کسب کار (Business logic) می‌باشد که توسط چندین آداپتور (جهت ارتباط با سایر سرویس‌ها) احاطه شده است.بیایید با دقت به هر یک از بخش‌های یک سرویس (با توجه به دیاگرام فوق) نگاه کنیم هر سرویس  احتمالا دارای یک یا چندین API می‌باشداز دید مصرف کنندگان یک سرویس (Consumers)، تنها مورد با اهمیت یک سرویس، APIهای آن سرویس می‌باشد. APIهای یک سرویس نیز (با توجه به تصویر فوق) شامل عملیات یا Operations و وقایع منتشر شده یا Published events می‌باشند. که در ادامه این انواع را بررسی میکنیم.عملیات (Operations)به صورت کلی و همانطور که در دیاگرام فوق قابل مشاهده می‌باشد، عملیات به دو نوع دستورات (Commands) و جستارها (Queries) تقسیم می‌شوند. دستورات نوعی از عملیات می‌باشند که موجب تغییر داده‌ها می‌شود؛ اما در مقابل جستارها، عملیاتی در جهت واکشی داده‌ها می‌باشند. برای مثال یک سرویس  ثبت سفارش (OrderService) را در نظر بگیرید. عملیاتی مانند ثبت سفارش ()CreateOrder، انصراف از سفارش ثبت شده  ()CancelOrder و ... عملیاتی از نوع دستورات هستند و عملیاتی مانند یافتن یک سفارش خاص ()FindOrder که هیچ دیتایی را تغییر نمیدهد، از نوع جستارها می‌باشند.عملیات ارائه شده توسط یک سرویس میتواند از ترکیبی از پروتکل‌های همزمان (Synchronous protocols) مانند REST یا gRPC و پروتکل‌های غیر همزمان (Asynchronous protocols) مانند messaging باشند.پروتکل‌های همزمان، به ویژه REST، بیشتر در مواردی که قصد ارائه API به کلاینت‌های خارجی (External clients) را داریم، مانند موبایل اپلیکیشن‌ها و یا نرم افزارهای تک صفحه‌ای (SPA) کاربرد دارند.از پروتکل‌های غیر همزمان مانند messaging نیز بیشتر در مواردی که میخواهیم الگوی ساگا (SAGA) را پیاده سازی نماییم و به روز نگه داشتن داده‌ها را بین سرویس‌های مختلف حفظ کنیم، نیاز به استفاده داریم. برای مثال در همان سیستم ثبت سفارش، عملیات ()CreateOrder به صورت Rest و با متد Post در Endpoint ای مانند /Order پیاده سازی می‌شود و پس از فراخوانی، یک عملیات غیرهمزمان مانند CreateOrderSaga را نیز به صورت messaging آغاز میکند.وقایع (Events)سرویس‌ها، اغلب وقایعی (Event) را نیز منتشر میکنند. منظور از وقایع یا events معمولا همان مفهوم domain event درDDD می‌باشد که در همان ادبیات DDD وقایع توسط aggregate‌ها در زمان هایی مانند ایجاد، ویرایش، حذف و یا سایر مفاهیم موجود در منطق کسب و کار منتشر می‌شوند. سرویس نیز معمولا این وقایع را روی یک کانال ارتباطی (message channel) که توسط یک message broker (مانند RabbitMQ, Apache Kafka, ActiveMQ و ...) پیاده سازی شده است، منتشر میکند. و علاقمندان به دریافت این وقایع می‌توانند وقایع را پس از انتشار، بر روی کانال ارتباطی دریافت نمایند.منطق کسب و کار (Business Logic) منطق کسب و کار، قلب هر سرویس و دلیل وجود آن سرویس می‌باشد که API هایی را در قالب عملیات (Opertaions) پیاده سازی و همچنین مواردی را در قالب وقایع (Events) منتشر می‌نماید. همچنین منطق کسب و کار می‌تواند بنا بر نیاز خود، عملیات مربوط به سایر سرویس‌ها را فراخوانی و یا در کانال‌های ارتباطی (channels) مربوط به وقایع آنها، مشترک (Subscribes) شود و نهایتا داده‌ها را در دیتابیس خود نگهداری نماید.نحوه همکاری سرویس‌ها با یکدیگر (Services Collaborations) با توجه به مفاهیم فوق، زمانی که صحبت از همکاری (collaborate) بین سرویس‌ها می‌شود، معمولا منظور، ارتباط آنها از طریق APIهای یکدیگر (شامل عملیات و وقایع که پیش‌تر توضیح داده شد) می‌باشد (به جای خواندن و نوشتن مستقیم در دیتابیس‌های مربوط به یکدیگر می‌باشد).برای مثال یک سرویس ممکن است عملیات مربوط به ایجاد سفارش ()CreateOrder را از سرویس ثبت سفارش (OrderService) فراخوانی نماید و یا برعکس خود سرویس ثبت سفارش (OrderService) ممکن است بر حسب نیاز منطق کسب و کار خود، عملیات ارائه شده توسط سرویس انبار را فراخوانی نماید.همچنین یک سرویس جهت همکاری با دیگر سرویس‌ها میتواند در وقایع منتشر شده (Published events) توسط آنها مشترک (Subscribes) شود. برای مثال سرویس ثبت سفارش احتمالا در وقایع منتشر شده از سوی سرویس رستوران مشترک می‌شود.دیتابیس اختصاصی معمولا هر سرویس دارای یک یا چند دیتابیس می‌باشد که دیتای اختصاصی مربوط به منطق کسب و کار خود و در مواردی بخشی از دیتای مربوط به سایر سرویس‌ها را در آن‌(ها) نگهداری میکند. برای مثال اطلاعات سفارش‌ها را هم سرویس ثبت سفارش و هم سرویس رستوران، هر دو نگهداری میکنند و عملا این دیتا ابتدا در سرویس رستوران و سپس در سرویس ثبت سفارش، مجددا نگهداری می‌شود و به نوعی دیتای فوق Replicate شده و تکراری می‌باشد. اما به جهت اطمینان از کاهش وابستگی (loose coupling) این تکرار داده‌ها انجام می‌شود. در مجموع استفاده از یک دیتابیس مشترک (منظور table مشترک می‌باشد) بین سرویس‌ها ایده‌ی بدی می‌باشد و سرویس‌ها باید از طریق API‌های یکدیگر باهم همکاری نمایند.نتیجه در این مقاله عنوان شد که میکروسرویس یک سبک معماری می‌باشد و در این معماری، نرم افزار و منطق کسب و کار، به چندین سرویس مختلف  تقسیم می‌شود. مشخصات کلیدی که هر سرویس باید در این سبک معماری (microservice architecture) داشته باشد و همچنین ساختار درونی هر سرویس بررسی شد.در قسمت بعدی این مقاله، در مورد نحوه مستند سازی این سرویس‌ها صحبت می‌شود. چرا که با زیاد شدن تعداد سرویس‌ها، در صورت عدم وجود یک مستندات مناسب (documents)، ارتباط و هماهنگی تیم‌ها با یکدیگر خود موجب سربار خواهد شد.منابعبرگرفته شده از مقاله آقای ریچاردسون (whats-a-service)مستند سازی میکروسرویس ها (قسمت دوم) محمود سواریان محمود سواریان Tue, 15 Dec 2020 22:34:06 +0330