"طراحی دامنه محور” یکی از رویکردهای اصلی در طراحی نرم افزار است. بطور کلی هدف این رویکرد این است که ساختار و زبان کد یک نرم افزار، باید با حوزه کسب و کار آن مطابقت داشته باشد. بعنوان مثال اگر در زبان کسب و کار نرم افزار عبارتی مانند مشتری (customer) داریم در ساختار کد هم چنین کلاسی داشته باشیم. این مسیله باعث به وجود آمدن یک زبان مشترک بین توسعه دهندگان و ذی نفع های پروژه نیز میشود که از یکی از نیاز های مهم یک پروژه نرم افزاری است.
برای درک بهتر نیاز است بدانیم domain به چه معناست. در اینجا دامنه (domain) به معنای حوضهای است که نرم افزار بر پایه آن در حال ساخت است. این معماری به ما کمک میکند تا بتوانیم بخش های مختلف نرم افزار (context) را از هم جدا کنیم (bounded context بسازیم) و بتوانیم این bounded context ها را به هم ارتباط دهیم ؛ به همین جهت این معماری بیشتر برای نرم افزار های بزرگ استفاده میشود و استفاده از آن برای نرم افزارهای کوچک توجیهی ندارد.
منابع :
http://www.atriya.com/Blog/ArticleDetails/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-domain-driven-design
https://en.wikipedia.org/wiki/Domain-driven_design
یک الگوی معماری (architectural pattern) در معماری نرم افزار است که نرم افزار را به سه بخش model , view و view model تقسیم میکند. در این الگو model مرکز دیتا و نگه داری کننده اطلاعات نرم افزار است.
ویو (view) در واقع بخش رابط کابری است و ذخیره اطلاعات و منطق نرم افزار در آن جایی ندارد. ViewModel در واقع رابط بین دو بخش view و model است، ViewModel وظیفه تغییر شکل داده ها و انتقال داده ها به شکلی که در view قابل نشان دادن باشد را دارد و میتواند view را آپدیت کند. همچنین ViewModel میتواند اطلاعات را از view بگیرد و به شکل درست به model انتقال دهد.
ارتباط بین بخش ظاهر برنامه (view) و منطق برنامه (model) توسط تکنیکی به اسم Data Binding انجام میشود. با استفاده از این تکنیک دیگر برنامه نویس مجبور نیست هر اطلاعاتی که تغییر میکند را در model تغییر دهد و نیز اطلاعات تغییر یافته در مدل به شکل خودکار در view تغییر میکنند. برای مثال تغییر نام کاربری در بخش view توسط کاربر بطور خودکار در model اعمال میشود.
این الگوی معماری به MVC شباهت دارد و تفوت آن با MVC در این است که در MVC مدل و ویو با هم ارتباط دارند ولی در MVVM مدل و ویو از وجود هم آگاه نیستند و ViewModel وظیفه ارتباط بین این دو را دارد.
منابع:
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
https://ditty.ir/posts/mvvm-pattern/XpAPJ
https://www.digitalocean.com/community/tutorials/android-mvvm-design-pattern
یک الگوی معماری قدرتمند است که تمام تغییرات ایجاد شده در وضعیت برنامه را به ترتیب رویداد اتفاق افتاده ثبت میکند. در اینگونه سیستم ها به جای اینکه آخرین وضعیت دیتا درون پایگاه داده ذخیره شود در این معماری همه ی رویدادها درون پایگاه داده ذخیره میشوند.
به وسیله event sourcing ما میتوانیم بر روی رویداد ها پرس و جو انجام بدهیم و همچنین میتوانیم با استفاده از این لاگ ها (رویداد های ثب شده)، حالت (state) قبلی برنامه را دوباره بسازیم (برای مواقعی که بعد از تغییرات در برنامه، برنامه به وضعیت نامطلوب و مشکل برخورد کند). نرم افزار هایی با این معماری رویداد ها را در یک مخزن رویداد (نوعی پایگاه داد) ذخیره میکنند پرس و جو ها (queries) در این گونه سیستم ها معمولا براساس زمان هستند. یک مثال رایج از برنامه‌هایی که از Event Sourcing استفاده میکنند، سیستم کنترل نسخه است. وضعیت فعلی آخرین کد منبع است و رویدادها کار هایی است که روی سیستم انجام شده است.
منابع:
https://martinfowler.com/eaaDev/EventSourcing.html
https://virgool.io/@arashrahimi46/event-sourcing-%DA%86%DB%8C%D8%B3%D8%AA-cnnc6vwjqj2o
معماری میکروسرویس در سال های اخیز محبوبیت زیادی پیدا کرده است و بسیاری از سازمان‌ها از این سبک معماری استفاده میکنند تا از محدودیت‌های بخش backend که جاببت بزرگ و یکپارچه پیدا میکنند اجتناب کنند.
معماری Micro-frontend یک رویکرد طراحی است که در آن یک برنامه front-end به "microapps" منفرد و نیمه مستقل تقسیم می شود که به طور آزاد با هم کار می کنند. ایده پشت Micro Frontends این است که در مورد یک وب سایت یا برنامه وب به عنوان ترکیبی از ویژگی هایی که متعلق به تیم های مستقل است فکر کنید. هر تیم دارای حوزه مشخصی از کسب و کار یا مأموریتی است که به آن اهمیت می دهد و در آن تخصص دارد.
معماری‌های Micro-frontend ساده‌تر هستند و بنابراین استدلال و مدیریت آن نیز آسان‌تر است، همچنین تیمهای توسعه مستقل میتوانند در توسعه نرم افزار front-end به آسانی با هم همکاری کنند. اگر چه در سال های اخیر micro frontend بسیار پر استفاده بوده است ولی از مشکلات این معماری میتوان به مشکلات هنگام دیپلوی کردن و تست و همچنین خود اینکه چطور برنامه را به microapp ها تقسیم کنیم اشاره کرد.
منابع:
https://www.toptal.com/front-end/micro-frontends-strengths-benefits
https://martinfowler.com/articles/micro-frontends.html
اLow Code development platform محیطی را برای کاربران فراهم میکند که بتوانند با میزان کد کم یا بدون کدنویسی برنامه نرم افزاری را پیاده سازی کنند. این محیط بیشتر گرافیک است و حتی کسانی که میزان کم آشنایی با برنامه نویسی دارند نیز میتوانند از این محیط اسنفاده کنند و در نتیجه افراد بیشتری میتوانند در پروژه را داشته باشند. از دیگر مزایای این محیط میتوان به کاهش زمان معمول در پروسه تولید نرم افزار و کاهش هزینه تولید نرم افزار اشاره کرد.
رویکردهای ماژولار کم کد و بدون کد به توسعه دهندگان حرفه ای نیز اجازه می دهد تا به سرعت برنامه ها را با بی نیازی از نوشتن کد خط به خط، بسازند. همچنین این محیط به تحلیلگران کسب و کار، مدیران اداری، صاحبان بیزینس های کوچک و کسانی که توسعه دهنده نرم افزار نیستند نیز اجازه میدهد که در این محیط کار کنند، برنامه تولید کنند و برنامه ها را آزمایش کنند.
از platform های پرطرفدار برای توسعه low-code میتوان به Appian ، Mendix ، OutSystems اشاره کرد.
منابع
https://www.trio.dev/blog/low-code-platforms
https://en.wikipedia.org/wiki/Low-code_development_platform
https://www.techtarget.com/searchsoftwarequality/definition/low-code-no-code-development-platform
اEnterprise Service Bus یک مدل ارتباطی و یک middleware است که به برنامه های تجاری اجازه میدهد که با هم ارتباط بر قرار کنند. بستر ESB شامل قوانین تجاری و استاندارد های رایج است. همچنین شامل پروسه و مکانیزمی است که پیام ها را از منبع به مقصد میرساند.
مدل Enterprise Servise Bus با بکار گیری قوانین معماری خدمتگرا (SOA) کمک میکند که نرم افزار راحتتر پیاده سازی شود. در این مدل به شکل فرضی یک ارائه کننده خدمت و یک مصرف کننده خدمت وجود دارد که این دو به وسیله پلی به هم متصلاند. در واقع این پل ارتباطی بین مصرف کننده و ارائه دهنده ESB است. هر کدام از این برنامه ها با ESB در تماس هستند و وظایف و کارهایی مانند فراخوانی API و message formatting و ... از این طریق انجام میگیرد.
مفهوم enterprise service bus مشابه مفهوم bus در معماری سخت افزار است. ESB به عنوان نرم افزار باید بتواند پیام های بین برنامه ها را از طریق bus خود انتقال دهد. برای دستیابی به این ESB باید عملکرد ارائه شده توسط برنامه های کاربردی اجزای خود را به روشی معنی دار محصور کند.
وظایف ESB شامل مسیریابی پیام ها بین سرویس ها، نظارت و کنترل مسیریابی سرویس ها و تبادل انها با سرویس ها، مرتب کردن استفاده از سرویس های اضافه شده و ... میباشد.
منابع:
https://en.wikipedia.org/wiki/Enterprise_service_bus
https://www.integrate.io/glossary/what-is-esb/
https://wso2.com/what-is-an-esb/
برای بررسی API gateway ابتدا به مفهوم API میپردازیم. API مخفف عبارت Application programming Interface و به معنی رابط برنامه نویسی اپلیکیشن است. در واقع API ها مکانیسم هایی هستند که دو جزء نرم افزار را قادر می سازند تا با استفاده از مجموعه ای از تعاریف و پروتکل ها با یکدیگر ارتباط برقرار کنند.
یک API gateway برنامه ای است که در مقابل یک API قرار میگیرد و نقطه ورود تکی برای API های Back-end و میکروسرویس‌های تعریف شده است. دروازه API بخشی از سیستم مدیریت API است. دروازه API تمام درخواست های دریافتی را رهگیری می کند و آنها را از طریق سیستم مدیریت API ارسال می کند که انواع توابع ضروری را مدیریت می کند. به بیان ساده، دروازه API تمام درخواست‌های API را از یک کلاینت دریافت میکند، مشخص میکند که کدام خدمات مورد نیاز است، و آنها را در یک حالت یکپارچه برای کاربر محیا میکند.
این دروازه (gateway) مسئولیت محافظت و برفراری امنیت و همچنین مسئولیت برفراری حداکثر دسترس پذیر را به عهده دارد. در نتیجه API ها به یک ضرورت استراتژیک برای مشاغل تبدیل شده اند چرا که آنها چابکی، یکپارچگی را تسهیل می کنند و در هنگام بزرگ شدن نرم افزار آنها بسیار کمک کننده هستند.
منابع:
https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do
https://microservices.io/patterns/apigateway.html
https://blog.faradars.org/what-is-an-api/
در علوم کامپیوتر، صف‌های پیام و صندوق‌های پستی اجزای مهندسی نرم‌افزار هستند که معمولاً برای ارتباطات بین فرآیندی (IPC) یا برای ارتباطات بین رشته‌ای (thread) در همان فرآیند استفاده میشوند. صف پیام شکلی از ارتباط سرویس به سرویس ناهمزمان است که در معماری های بدون سرور و میکروسرویس استفاده می شود. پیام ها تا زمانی که پردازش و حذف شوند در صف ذخیره می شوند و هر پیام فقط یک بار توسط یک مصرف کننده پردازش می شود.
در معماری نرم افزار مدرن، برنامه‌ها به بلوک‌های ساختمانی کوچک‌تر و مستقل تقسیم میشوند که بتوانند راحتتر توسعه، استقرار و نگهداری شوند. صف های پیام ارتباط و هماهنگی را برای این برنامه های توزیع شده فراهم می کنند. صف های پیام می توانند به طور قابل توجهی برنامه نویسی برنامه های جدا شده را ساده کنند، در حالی که عملکرد، قابلیت اطمینان و مقیاس پذیری را بهبود می بخشند.
به عنوان مثال نرم افزار RabbitMQ به عنوان یک پلتفرم واسطه کار می کند که تضمین می کند پیام به مقصد مناسب تحویل داده می شود. از این نرم افزار می توان برای کاهش بار و زمان تحویل web application serverبا واگذاری وظایفی که معمولاً زمان یا منابع زیادی را به شخص ثالثی که کار دیگری ندارد، استفاده کرد.
منابع:
https://aws.amazon.com/message-queue/
https://en.wikipedia.org/wiki/Message_queue
https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html
https://www.rabbitmq.com/
