طبق تعریف microservice از زبان جناب martin fowler

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage
technologies. 

من در مورد همه مشکلات میکرو سرویس زیاد با شما موافق نیستم 

من تجربه خوبی در کار با topshelf  داشتم که دوستان تو این پس هم معرفی کردن

به دوستان پیشنهاد می‌شه این رو هم ببینید 

مثل اینکه async  کردن متد‌های  Repository زیاد پیچیده نمی‌باشد !

پس می‌شه query ‌های NH  رو هم Async  کرد ، پس روی IRepository  می‌تونیم هم متد Async  هم متد Sync  رو با هم داشته باشیم

در مورد async  راست می‌گید ! باید ببینم راهی داره یا نه ، در ضمن در لایه دیتا اکسس هر جور که می‌خواهید می‌تونید include  و غیره بزنید مشکلی وجود نداره ، چون رو اینتفریس از شما می‌خواهند که یک entity  چه چیزهایی همراهش باشه یا نباشه
خوب اگه به cqrs  نگاه کنید در سمت Command  شما قسمت اصلی و insert , Update , delete  و Get  رو دارید و برخی مواقع getall  که خیلی کمه ولی سمت query  کاملا دستتون بازه هر جور که کار کنید کلا پشت query سرویس هر جور که راحتی با هر چی که راحتی کار کن !

پیاده سازی خوبیه
البته زمانی که از DDD  استفاده می‌شه  استفاده از IQueryable  در IRepository  به عنوان نشت اطلاعات خوانده می‌شود و تاکیدا نباید استفاده شود !

این Repository ‌های Generic  میتوانند داخل یک کلاس که IRepository  را Implement  کرده استفاده شوند و یا به عنوان کلاس Base  ان باشند

تو مبحث DDD  دلیل اصلی که Repository  وارد داستان شده Persistence Ignorance  می‌باشد ،
همونطور که میدونید ، این  قضیه می‌گه که شما تو  Domain  نبایید بگید EF  این طوری Select  می‌زنه Nhibernate   یک نوع دیگر ، NoSql  یک نحو دیگر (NoSql ‌ها هم بخاطر اینکه میتونند براحتی یک Aggregate  رو ذخیره کنند  میتونند ابزار خوبی برای DDD  باشند! )
چون Domain  نباید به تکنولوژی وابسته باشد ! نباید رفرنسی به دیتا اکسس یا  EF  و یا ... داشته باشد فقط یک سری Interface  تعریف می‌کند ، که یکی که بعدا به نام لایه دیتا اکسس می‌باشد باید این اینترفیس  رو Implement  کتد !
در مورد CQRS  هم چون معمولا Application Layer  بر روی Rest هاست می‌شوند پس هر Request  فقط شامل یک Command  می‌باشد که Unit Of work  رو هم فقط روی همان Command  ایجاد می‌کنند
جالبه براتون بگم که در Domain Driven Design    اصل بر این هست که شما در هر ترانزاکشن فقط یک Aggregate  رو باید ذخیره کنید و تغییر در Aggregate ‌های دیگه بوسیله Event Source ‌ها Publish  می‌شه

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

با توجه به متن قضاوتتون عجولانه است !

تو پروژه‌های Huge که  توصیه  خود مایکروسافت استفاده از Domain Driven  و CQRS  می‌باشد ، Repository  یکی از اصول Domain Driven  و Enterprise Application Pattern  می‌باشد ! 

یک کار خوب داخل دیگه اینه که یک Local Package Source  در شرکت داشته باشیم که دچار گیر کردن گاه به گاه ،مشکلات nuget  تو ایران که بعضی وقتها گیر می‌کنه نیافتیم و package  با سرعت بالا نصب بشوند