من نمی دونم اگه این تعرفه هست ، چرا ما هیچی نمی بینیم ، این تعرفه ها تقسیم بر 3 میشه حقوق ماها تقریبا اونهم اگه جای خوبی باشیم

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

ولی به نظر من اقدام خوبیه شاید در 10 سال آینده به جاهای خوبی برسه

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

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

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

اگر این کتابخانه‌ها نبودند و امروزه تا این حد تکامل پیدا نکرده بودند، هیچ وقت سیلورلایت و فلش از صحنه روزگار محو نمی‌شدند. در بسیاری از اوقات هدف ساخت یک برنامه غنی وب است. برنامه‌ای که تجربه کاربری آن همانند برنامه‌های دسکتاپ باشد. مثلا صفحه مدام چشمک نمی‌زند و کاربر احساس نمی‌کند که مدام رفت و برگشت به سرور وجود دارد، کنترل‌های auto-complete مانند برنامه‌های دسکتاپ و یا حتی شکیل‌تر و غنی‌تر از آن‌ها در وب وجود دارند، برنامه‌های تک صفحه‌ای وب، اعتبار سنجی‌های سمت کاربر، بدون هدایت او به سرور و دریافت پاسخ آنی و بسیاری از مثال‌های دیگری که در جهت بهبود کاربری در وب مطرح هستند. در اینجا HTML خالص بدون جاوا اسکریپت حرفی برای گفتن ندارد. HTML خالص صرفا جهت ارائه محتوا اختراع شده است نه طراحی برنامه‌های غنی وب و کار ما هم با ASP.NET و یا فناوری‌های مشابه، تولید برنامه‌های وب است و نه صرفا ارائه محتوا. اگر قرار است مثلا چند صفحه توضیح مشخصات شرکتی را در اینترنت قرار دهید، این تنها به معنای ارائه‌ی محتوا است. نیازی به برنامه خاصی ندارد. چند صفحه HTML به همراه مقداری هم CSS برای اینکار کافی است. اما اگر همینجا قرار شد از کاربر اطلاعات دریافت کنید، نیاز است تجربه کاربری او را غنی کنید.

دقیقا همینطور هست. در اینجا فناوری‌های سمت سرور فقط تبدیل به ارائه کننده‌ی وب سرویس می‌شوند و نه بیشتر.
مزیت آن این است که شما با Razor فقط یک سری فرم‌های ابتدایی و اعتبارسنجی آن‌ها را به خوبی می‌توانید مدیریت کنید. یک مقدار کار UI که پیچیده‌تر شد، به صفحه‌ای می‌رسید که درون آن 100ها سطر کد جی‌کوئری با کدهای Razor مخلوط شدن و 2 ماه بعد حتی جرات نمی‌کنید به این صفحه دست بزنید و تغییری را در آن اعمال کنید. اینجا است که فریم ورک‌های SPA ارزش خودشان را نشان می‌دهند.
برای فرم‌های معمولی، Razor عالی است. برای UI پیچیده، ترکیب Razor و jQuery اصلا قابلیت نگهداری ندارد (صفحاتی پر از قطعات جاوا اسکریپت که نه فضای نامی دارند، به راحتی تداخل می‌کنند، عموما از TypeScript استفاده نمی‌کنند و مبتنی بر قابلیت‌های جدید این زبان نیستند). در یک چنین حالتی قابلیت تست UI را هم از دست خواهید داد. همچنین مدام هم محدود به افزونه‌های جی‌کوئری خواهید بود، اما با فریم ورک‌های SPA، خیلی از این افزونه‌ها، کارهای معمولی آن‌ها هستند. به علاوه زمانیکه back-end (سمت سرور) و front-end (مدیریت کدهای سمت کلاینت) را از هم جدا می‌کنید، بهتر می‌توانید از مزیت کار با طراحان UI استفاده کنید. کسانیکه عموما قرار نیست با کدهای سمت سرور کار کنند. 

- یک سری micro orm مانند Dapper وجود دارند که اساس کار آن‌ها، کوئری نویسی و سپس دریافت اطلاعات از طریق لیست‌های جنریک (مانند روش نهایی کار در مثال جاری) است. بنابراین datatable را فراموش کنید و شروع کنید به استفاده از dapper یا peta poco (اگر نمی‌خواهید از Entity framework استفاده کنید).
- مهم این نیست که منبع داده‌ی شما به چه نحوی تهیه می‌شود. مهم این است که این گرید خاص و امثال آن (Kendo UI هم به همین صورت)، داده‌ها را با فرمت JSON دریافت می‌کنند. همچنین داده‌ها را با فرمت JSON به سمت سرور ارسال می‌کنند. بنابراین مطابق مثالی که زده شد، اطلاعات خودتان را تبدیل می‌کنید به فرمت new JqGridData و سپس آن‌را به صورت JSON بازگشت می‌دهید. همچنین در سمت کاربر، تمام تغییرات، با فرمت JSON به سمت سرور ارسال می‌شوند که این مورد و آنالیز آن در قسمت‌های بعدی این سری بررسی شده‌اند.
- در این سری مثال‌ها از امکانات توکار ASP.NET MVC برای بازگشت داده‌ها به صورت JSON استفاده شده‌است. اما jqGrid یا Kendo UI Grid و امثال آن‌ها اساسا هیچگونه وابستگی به فناوری‌های سمت سرور ندارند. بنابراین از یکی از روش‌های موجود بازگشت اطلاعات به فرمت JSON استفاده کنید. مهم هم نیست که برنامه‌ی شما ASP.NET MVC است یا وب فرم یا PHP یا هر چی. برای مثال از کتابخانه‌ی JSON.NET برای بازگشت اطلاعات به فرمت JSON استفاده کنید.
- علاوه بر این، روش‌های دیگری هم برای بازگشت اطلاعات به فرمت JSON وجود دارند. اطلاعات بیشتر

 معماری میکرو سرویس یا یکپارچه؟

برای درک میکروسرویس‌ها، باید بدانیم کاربرد سیستم‌های یکپارچه چیست و چه چیزی باعث شد در زمان‌های اخیر از برنامه‌های یکپارچه به میکروسرویس‌ها حرکت کنیم.

 سیستم‌های یکپارچه ( Monolithic applications  )

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

چرا اصلا به سمت میکروسرویس‌ها برویم؟

خب برای جواب به این سوال بهتر است معایب سیستم‌های یکپارچه را مرور کنیم:

1. مدیریت دشوار بخاطر گسترش برنامه در گذشت زمان
2. برای تغییری کوچک، کل برنامه را دوباره باید منتشر ( publish ) کنیم
3. با تغییر و آپدیت برنامه، زمان انتشار افزایش می‌یابد.
4. درک دشوار برای توسعه دهنده‌های جدید هر پروژه
5. برای تقسیم ترافیک روی قسمت‌های مختلف برنامه، باید نمونه‌های کل برنامه را در چندین سرور منتشر کنیم که بسیار ناکارآمد و باعث استفاده‌ی بیهوده از منابع میشود
6. اگر از فناوری یا تکنولوژی‌های جدید استفاده کنیم، برای عملکردی خاص، چه از نظر هزینه و چه از نظر زمان، بر کل برنامه تاثیر گذار است
7. و در نهایت وجود یک باگ در هر ماژول میتواند کل برنامه را مختل کند.

و اما مزایای سیستم‌های یکپارچه:

1. توسعه‌ی آن نسبت به میکروسرویس‌ها ساده است.
2. انتشار آن آسان‌تر است؛ زیرا فقط یک خروجی، مستقر شده‌است.
3. در مقایسه با معماری میکروسرویس‌ها، توسعه‌ی آن نسبتا آسان‌تر و ساده‌تر است.
4. مشکلات تأخیر و امنیت شبکه در مقایسه با معماری میکروسرویس‌ها نسبتاً کمتر است.
5. توسعه دهندگان نیازی به یادگیری برنامه‌های مختلف ندارند؛ آنها می‌توانند تمرکز خود را بر روی یک برنامه حفظ کنند.

میکروسرویس ها

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

معماری میکروسرویس تأثیر بسزایی در رابطه‌ی بین برنامه و پایگاه داده دارد. بجای اشتراک گذاری یک پایگاه داده با سایر میکروسرویس‌ها، هر میکروسرویس، پایگاه داده خاص خود را دارد که اغلب منجر به تکثیر برخی از داده‌ها می‌شود، اما اگر می‌خواهید از این معماری بهره مند شوید، داشتن یک پایگاه داده در هر میکروسرویس، ضروری است؛ زیرا اتصال ضعیف را تضمین می‌کند. مزیت دیگر داشتن یک پایگاه داده‌ی مجزا برای هر میکروسرویس این است که هر میکروسرویس می‌تواند از نوع پایگاه داده‌ای که برای نیازهای خود مناسب‌تر است، استفاده کند. هر سرویس یک ماژول را ارائه می‌دهد، به طوری که خدمات مختلف را می‌توان به زبان‌های برنامه نویسی مختلف نوشت. الگوهای زیادی در معماری میکروسرویس دخیل هستند مانند discovery و registry service ، Caching ، ارتباط API ، امنیت و غیره.

اصول میکروسرویس‌ها:

تک مسئولیتی: یکی از اصولی است که به عنوان بخشی از الگوی طراحی SOLID تعریف شده است. بیان می‌کند که یک Unit ، یا یک کلاس، یک متد یا یک میکروسرویس باید تنها یک مسئولیت را داشته باشد. هر میکروسرویس باید یک مسئولیت داشته باشد و یک عملکرد واحد را ارائه دهد. شما همچنین می‌توانید بگویید تعداد میکروسرویس‌هایی که باید توسعه دهید، برابر با تعداد عملکردهای مورد نیاز شما است. پایگاه داده نیز غیرمتمرکز است و به طور کلی، هر میکروسرویس، پایگاه داده خاص خود را دارد.

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

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

مزایای میکروسرویس ها:

1. مدیریت آن آسان است زیرا نسبتا کوچکتر است.
2. اگر در یکی از میکروسرویس‌ها، بروزرسانی وجود داشته باشد، باید فقط آن میکروسرویس را مجدداً منتشر کنیم.
3. میکروسرویس‌ها مستقل هستند و از این رو به طور مستقل منتشر می‌شوند. زمان راه اندازی و انتشار آنها نسبتاً کمتر است.
4. برای یک توسعه‌دهنده جدید بسیار آسان است که وارد پروژه شود، زیرا او باید فقط یک میکروسرویس خاص را که عملکردی را که روی آن کار می‌کند، درک کند و نه کل سیستم را.
5. اگر یک میکروسرویس خاص به دلیل استفاده بیش از حد کاربران از آن عملکرد، با بار زیادی مواجه است، ما باید فقط آن میکروسرویس را تنظیم کنیم. از این رو، معماری میکروسرویس از مقیاس بندی افقی پشتیبانی می‌کند.
6. هر میکروسرویس بر اساس نیازهای تجاری می‌تواند از فناوری‌های مختلفی استفاده کند.
7. اگر یک میکروسرویس خاص به دلیل برخی باگ‌ها از کار بیفتد، بر روی سایر میکروسرویس‌ها تأثیر نمی‌گذارد و کل سیستم دست نخورده باقی می‌ماند و به ارائه سایر عملکردها به کاربران ادامه می‌دهد.

معایب میکروسرویس ها:

1. پیچیده است و پیچیدگی آن با افزایش تعداد ریز سرویس‌ها افزایش می‌یابد.
2. نیاز به نیروهای متخصص
3. استقرار مستقل میکروسرویس‌ها پیچیده‌است.
4. میکروسرویس‌ها از نظر استفاده از شبکه پرهزینه هستند؛ زیرا نیاز به تعامل با یکدیگر دارند و همه این تماس‌های راه دور منجر به تأخیر شبکه می‌شود.
5. امنیت کمتر به دلیل ارتباط بین سرویس‌ها
6. اشکال زدایی دشوار است