شما اینجا هستید: خانه / مقالات آموزشی / آشنایی با مفاهیم Domain-Driven Design – بخش چهارم

آشنایی با مفاهیم Domain-Driven Design – بخش چهارم

این مطلب چهارمین بخش از سری مقالات آموزشی Domain Driven Design می باشد. برای مطالعه ی بخش های قبل میتوانید از لینک های زیر استفاده نمایید :

پیش گفتار : مقدمه ای بر Domain-Driven Design

بخش اول : آشنایی با مفاهیم Entity، Value Object و Service

بخش دوم : آشنایی با مفاهیم Invariant، Aggregate و Aggregate Root

بخش سوم : آشنایی با مفاهیم Subdomain و Bounded Context

 

  • پیشگفتار

یکی از اصلی ترین اهداف DDD، تمرکز کامل بر روی Business و فرآیندهای آن و جداسازی کامل آن از دغدغه های فنی و جزئیات پیاده سازی می باشد. تمام آنچه در مطالب قبل مطرح شد پیرامون نحوه ی مدل کردن Domain و تکنیک های طراحی آن بود. در این مقاله قصد داریم تا به معماری نرم افزار و نحوه ی لایه بندی نرم افزار جهت جداسازی Domain از قسمت های دیگر، بپردازیم.

  • معماری لایه ای

همانطور که میدانید جهت جداسازی بخش های مختف نرم افزار و پیاده سازی اصل SoC ، نرم افزار به لایه های مختلف تقسیم می شود که هر یک بر روی یک بخش از نرم افزار تمرکز دارند. این معماری با نام معماری لایه ای (Layered Architecture) شناخته می شود. معماری لایه ای سنتی اغلب با رویکرد داده محوری (Data-Driven) طراحی و استفاده میشد. تصویر زیر یک معماری لایه ای سنتی را نشان می دهد :

تصویر از کتاب Microsoft .Net: Architecting Applications for the Enterprise

تصویر از کتاب Microsoft .Net: Architecting Applications for the Enterprise

گذشت زمان و پیچیده تر شدن نرم افزارها تغییرات عمده ای در معماری لایه ای پدید آورد. رشد تفکر DDD و ایده ی تمرکز بر روی Domain و ایزوله کردن آن باعث گردید تا لایه ی Domain به عنوان قلب نرم افزار شناخته شده و جزئیات زیرساختی از دید آن مخفی بماند. هرچند DDD اجباری بر استفاده از معماری خاصی ندارد، اما بعضی معماری ها مانند معماری پیاز (Onion Architecture) توانستند موفقیت بیشتری در پیاده سازی اصول DDD و ایزوله کردن Domain داشته باشند.

  • معماری پیاز (Onion Architecture)

عبارت “Onion Architecture” اولین بار توسط آقای Jeffery Palermo و در سال ۲۰۰۸ مطرح گردید. ساختار یک معماری لایه ای پیاز را در شکل زیر مشاهده میکنید :

تصویر از وب سایت planetgeek.ch

تصویر از وب سایت planetgeek.ch

در این معماری هر لایه، به لایه ی داخلی تر وابسته بوده و به آن دسترسی دارد. لایه های داخلی هیچ Reference و اشاره ای به لایه های بالاتر ندارند. هرچند می توانند با ارسال Event آنها را از وقوع رویدادی باخبر کنند. همانطور که در شکل مشاهده میکنید لایه ی Domain، داخلی ترین لایه بوده و به هیچ لایه ی بیرونی وابستگی ندارد. این معماری با تکیه بر اصل Dependency Inversion تمام وابستگی های لایه ی Domain را در قالب Interface ها در اختیار آن قرار می دهد تا این لایه از جزئیات پیاده سازی و وابستگی به ابزارهای زیر ساختی در امان باشد.

  • Domain Layer

این لایه که به عنوان قلب نرم افزار شناخته می شود، مسئول پیاده سازی مفاهیم و قوانین Business می باشد. این لایه در قالب Entity ها، Value Object ها و سرویس ها پیاده سازی میشود (جهت اطلاعات بیشتر به بخش اول مراجعه کنید) . این لایه به هیچ لایه ی دیگری وابستگی ندارد و در صورت نیاز به لایه های زیرساختی (مانند دیتابیس) تنها به Interface آنها دسترسی پیدا میکند.

  • Application Service Layer

به طور کلی این لایه منطق نرم افزار (به اصطلاح Application Logic) را مدیریت و پیاده سازی می کند. این لایه از متدهایی تشکیل شده که بر اساس Use Case های سیستم تعریف شده اند. لایه ی Presentation درخواست های خود را به لایه ی Application ارسال کرده و این لایه با توجه به درخواست دریافت شده، از لایه های Domain و لایه های زیر ساختی برای انجام درخواست استفاده میکند. Application Service ها اغلب به عنوان نقطه ورودی (Entry Point) در سیستم شناخته می شوند. اگر چه در بسیاری از نرم افزارها، یک لایه Service (مانند سرویس های SOAP و یا RESTful) بر روی Application Service ها نیز قرار میگیرد که مسئول پیاده سازی زیر ساخت جهت ارتباط با Client ها می باشد.

– تفاوت Application Logic و Domain Logic چیست ؟

Application Logic عبارت است از قدم های مشخص جهت اجرای یک Use Case در سیستم. این قدم ها می تواند شامل بازیابی چند شیء Domain از دیتابیس، استفاده از آنها برای اجرای یک فرآیند، ارسال آنها برای ذخیره شدن در دیتابیس، صدا زدن سرویس های دیگر و … باشد. Application Service ها در واقع اعمال Business را انجام نمی دهند اما قدم های مختلف جهت اجرای آنها را می دانند و لایه های دیگر را جهت انجام شدن آن مدیریت میکنند. اما Domain Logic شامل مفاهیم و قوانین Business بوده و کاملا از جزئیات فنی جدا می باشد.

  • Infrastructure Layer

تمام زیر ساخت های داده ای و تکنولوژی محور نرم افزار در این لایه پیاده سازی می شوند. دسترسی به داده ها (Data Access)، دسترسی به وب سرویس های متفرقه (مانند ارسال پیامک و …) و همچنین زیر ساخت های Cross-Cutting (مانند Logging، Caching و … ) در این لایه پیاده سازی می شوند.

  • Presentation Layer

این لایه مسئول نمایش اطلاعات و همچنین مهیا کردن ابزاری برای دریافت اطلاعات از کاربر می باشد. این لایه داده ها را اغلب از لایه ی Application Service در قالب View Model دریافت کرده و نمایش می دهد.

حال که با ساختار کلی معماری پیاز آشنا شدید، بد نیست کمی با الگوی CQRS آشنا شویم.

الگوی CQRS

آقای Betrand Meyer در کتاب Object Oriented Software Construction (بر اساس اصل SoC) عنوان می کند که متد های یک شیء باید فقط اجرا کننده ی دستور (Command) و یا اجرا کننده ی Query باشند. Query ها تنها داده برمیگردانند و در وضعیت فعلی سیستم تغییری ایجاد نمیکنند و در مقابل Command ها باعث ایجاد تغییرات در سیستم شده ولی مقداری بر نمیگردانند. CQRS که اولین بار توسط آقای Greg Young مطرح گردید، از این اصل برای تعریف یک الگوی ساده استفاده میکند. پیاده سازی این الگو باعث می شود تا بسیاری از دغدغه های معماری نرم افزارتان (مانند انعطاف پذیری، مقیاس پذیری، تمرکز کامل بر فرآیندهای Domain و …) را برطرف کنید. تصویر زیر ساختار کلی الگوی CQRS را نشان می دهد :

تصویر از کتاب Exploring CQRS and Event Sourcing

تصویر از کتاب Exploring CQRS and Event Sourcing

همانطور که در تصویر مشاهده میکنید، نرم افزار به دو بخش خواندن (Read Side) و بخش نوشتن (Write Side) تقسیم شده است. اشیاء موجود در بخش خواندن تنها مسئول خواندن و بازیابی اطلاعات از دیتابیس بوده و اشیاء موجود در بخش نوشتن تنها مسئول اجرای Command های دریافتی می باشند.  در اغلب سیستم های اطلاعاتی تعداد خواندن اطلاعات از نرم افزار بسیار بیشتر از تعداد نوشتن است. جدا سازی این دو بخش شما را قادر می سازد که بر روی هر بخش به طور مستقل و جداگانه کار کنید و پیاده سازی هر کدام را بنا بر نیاز آن انجام دهید. برای مثال هنگام خواندن اطلاعات میتوانید از یک پایگاه داده ی نرمال نشده جهت افزایش سرعت استفاده نمایید و یا نوشتن اطلاعات را در یک پایگاه داده ی NoSQL انجام دهید.

نکته : اگرچه تصویر فوق دو پایگاه داده مختلف را در الگوی CQRS نشان می دهد، اما این امر الزامی نیست. CQRS می تواند بر روی یک دیتابیس ولی با دو مدل متفاوت برای نوشتن و خواندن اعمال شود.

عموما Command ها با منطق پیچیده ای جهت چک و اطمینان از صحت فرآیندهای سیستم درگیر هستند و این در حالی است که Query ها تنها عمل ساده ی خواندن را انجام می دهند. پیاده سازی یک مدل جهت برآورده ساختن نیازهای هر دو بخش سیستم اغلب صد در صد موفقیت آمیز نخواهد بود و ممکن است باعث شود تا گاهی مدل Domain را بنابر نیاز یک Query تغییر دهید. همانطور که در بخش سوم عنوان شد، در رویکرد DDD هر Bounded Context می تواند معماری مخصوص به خود را داشته باشد. با توجه به این رویکرد، CQRS را نباید الگویی برای کل سیستم در نظر گرفت، بلکه CQRS الگویی است که به یک و یا چند Bounded Context (با توجه به نیاز) اعمال میگردد.

  • نقش دستورات و رویدادها (Commands & Events) در CQRS 

استفاده از Command ها امری ضروری در پیاده سازی CQRS می باشد. هر Command در واقع درخواستی برای انجام عملیاتی در سیستم می باشد. برای مثال “مشتری با کد X را از سیستم حذف کن” و یا “رمز عبور کاربر Y به عبارت Z تغییر یابد”. Command ها معمولا یک بار و توسط یک شیء پردازش می شوند.

رویدادها (Events) نیز جنبه ی اطلاع رسانی دارند و از اتفاقی که در سیستم افتاده است خبر می دهند. برای مثال “سفارش با کد X در سیستم ثبت گردید” و یا “تعداد X از کالای Y از انبار خارج گردید”. Event ها میتوانند چندین بار و توسط چندین شیء پردازش شوند.

هم رویدادها و هم دستورات در قالب پیام (Message) هستند و جهت تبادل اطلاعات بین اشیاء استفاده می شوند. در رویکرد DDD این پیام ها در قالب پیام های معنی دار برای Business بوده و بخش های مختلف سیستم را قادر می سازد تا با دریافت آنها، عمل مخصوصی را جهت تکمیل فرآیند های Business انجام دهند. همانطور که در پاراگراف قبل مطرح شد در مدل CQRS می توان از پایگاه های داده ی مختلفی در بخش Read و Write استفاده کرد. بخش Write دستورات را از UI دریافت کرده و پس از انجام آنها، با ارسال Event بخش Read را جهت به روز رسانی پایگاه داده (و یا هر عمل متناسب دیگری) مطلع می سازد :

تصویر از کتاب Exploring CQRS and Event Sourcing

تصویر از کتاب Exploring CQRS and Event Sourcing

 

اگرچه پیاده سازی CQRS در پروژه های غیر DDD نیز امکان پذیر است اما نوع ماهیت پروژه های DDD و پیچیدگی آنها باعث شده است تا این الگو اغلب در پروژه های Domain-Driven پیاده سازی شود. در آینده به مزایای استفاده از CQRS و نوع پروژه های مناسب برای اعمال CQRS بیشتر میپردازیم.

درباره هادی احمدی

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

35 نظر

  1. بسیار زیبا و روان … امیدوارم این آموزشها ادامه داشته باشد .
    بسیار ممنون

  2. تشکر انشالله همه مطالبو میگید!

  3. خیلی خوبه.
    امیدوارم ادامه داشته باشه
    دستتون درد نکنه

  4. هادی احمدی

    سلام
    لطف دارید، امیدوارم مطالب براتون مفید واقع بشه

  5. سلام هادی جان کار خوبی رو شروع کردی، خیلی خوب بود ادامه بده

    موفق باشی

  6. سلام هادی جان

    یه سوال داشتم

    http://8pic.ir/images/2ixi5ls479c7x08jereh.png

    با توجه به شکل

    با فرض اینکه کلاس های من Anemic Domain Model نیستند و Encapsulation رعایت شده

    کلاس Country :
    فکر کنم Value Object باشه در این طراحی
    در Database
    برای Country یک Table دارم و لیست کشورها در آن ذخیره شده اند (اطلاعات پایه)
    و روی جدول Person کلید خارجی دارد

    یه درخواست از کلاینت برای ساخت یک Person به Application رسیده
    من در Application با توجه به اطلاعاتی که روی یک PersonDTO وجود دارد باید از کلاس Person (دامین مدل) یک نمونه بسازم ولی نباید از کلاس Country شی ای بسازم (چون مقدار Country در بانک وجود دارد) ، میخواهم با توجه به Country که روی Person (مدل کلاینت) وجود دارد، بررسی کنم که این Country در بانک اطلاعاتی وجود دارد یا خیر، اگر وجود دارد بزارم روی کلاس Person (دامین مدل) و فرآیند ذخیره Person را انجام دهم.

    ولی این ابهام برای من وجود دارد که من در کدام لایه (Domain یا Application) باید این بررسی رو انجام بدم ؟

    به نظرم این بررسی باید از طریق Domain Service در کلاس Person (دامین مدل) انجام شود،
    در این حالت :
    در سازنده کلاس Person باید :
    ۱- ICountryDomainService را بزارم
    ۲- برای ملیت ورودی رو از جنس Country نگیرم، فقط نام کشور را بزارم.

    و اینکه آیا درست هست ورودی یا خروجی متد های Domain Service هارو از جنس کلاس های Domain Model بگیریم ؟

    میبخشید طولانی شد

    ممنون میشم اگر راهنماییم کنید

    • هادی احمدی

      سلام محمد جان

      Country در این مثال به هیچ وجه Value Object نیست.
      درخواستی که از سمت Client برای شما ارسال می شود، باید همراه با ID کشور باشد (برای مثال کاربر از Dropdown انتخاب کرده) و شما هم با استفاده از این ID کشور را از Repository مربوطه بازخوانی کنید و به Consturctor کلاس Person ارسال کنید. این خواندن داده ها از Repository و ارسال آن به سازنده ی کلاس Person در لایه ی Application انجام میگیرد.

      • سلام

        من فکر کردم Value Object هست

        ممنون از راهنماییت

        یه مساله راجع اینکه فرمودید ComboBox بزارم، و آی دی Country بدم به Repository و Country رو بگیرم بدم به Person:

        – چون کلاینت WCF هست به همین دلیل به صورت دستی میتونه Country رو new کنه و یه آبجکت نامعتبر بسازه
        – من خود Country رو به سازنده Person بدم یا CountryId ؟

        ممنون

        • هادی احمدی

          سلام محمد جان
          – شما از سمت کلاینت (چه WCF، چه Web API) فقط ID مربوط به کشور رو دریافت میکنید. در Application Service (یا در Command Handler در مدل CQRS) از این ID استفاده میکنید تا کشور رو از Repository لود کنید. اگر کلاینت ID نامعتبر فرستاده باشد، هیچ داده ای لود نمی شود و میتوانید پیام خطا بدهید. (یعنی سناریوی فرستادن Country نامعتبر منتفی است)

          – به دو دلیل بهتر است در سازنده ی Person از Country استفاده شود تا CountryId :

          ۱٫ شما را ملزم میکند تا یک بار Country را از Repository بازیابی کنید و مطمئن شوید که Id فرستاده شده در دیتابیس وجود دارد.
          ۲٫ ممکن است Assign کردن Country به Person نیازمند چک کردن یک Business Rule باشد. برای مثال Person بررسی میکند که آیا Country که به آن Assign می شود شرط X را دارد یا خیر. که اینکار با Id قابل انجام نیست.

          موفق باشید

  7. سلام هادی جان

    میبخشید فکر کردم روال بررسی وجود Country در Database باید در کلاس Person (دامین مدل) انجام شود، پس شما میفرمائید این یک business rule نمیباشد، من با توجه به مثال زیر فکر کردم این یک Domain Logic هست:

    یک شرکت روال ثبت نام نیروی انسانی خود را میخواد به سیستم مکانیزه تبدیل کند:

    در روال سنتی یک فرم مشخصات فردی (کاغذی) وجود دارد که یکی از گزینه هایی که فرد باید پر کند کشور محل تولد است

    خب اگر فرد، کشور محل تولد خود را در فرم اشتباه بنویسد (مثلا بنویسد تهران)، فرد مسئول فرم را بررسی میکند و در صورت اشتباه ، فرم را به فرد بر می گرداند تا تصحیح کند

    من با این تحلیل به این نتیجه رسیده بودم که این Rule باید در Domain چک شود، و مربوط به Domain هست نه Application، و به اشتباه افتاده بودم.

    و اینکه نمیدونستم در کلاس Person باید Country بزارم یا CountryId ؟ چون اگر درست بگم ارتباط Entity ها با یکدیگر از طریق Id بود.

    واقعا ازت ممنونم بابت اینکه وقت میزارید پاسخ میدید

    من نمیخوام خیلی مزاحمت بشم،

    میدونم خیلی سرت شلوغه،

    این بحثم چون شروع کردم دیگه ادامش رو پرسیدم، سعی میکنم سوالهای این مدلی رو که نیاز به توضیح زیاد دارد رو اینجا مطرح نکنم

    ممنون ازت

    • هادی احمدی

      سلام محمد جان

      این چیزی که میفرمایید (صرف وجود Country در دیتابیس) در این مثال Business Rule نیست. میتوانید بگویید Country باید وقتی به Person وصل می شود حتما مقدار داشته باشد (که میتوانید در سازنده ی Person مقدار داشتن آن را چک کنید).

      نکته ی دیگر اینکه ارتباط از طریق Id همچنان سرجای خودش باقی هست. شما فقط Country را روی Constructor میگذارید و Rule های مورد نظرتان را چک میکنید اما روی Person فقط CountryId را نگه میدارید.

      خواهش میکنم، موفق باشی

  8. درسته متوجه شدم.

    میبخشید استاد فقط یه چیز دیگه، شما میفرمائید در سازنده Person مقدار داشتن Country چک شود، حالا بررسی اینکه این Country معتبر هست یا نه (اسم کشور و ID معتبر میباشد یا خیر) چون در Application از دیتابیس Country رو بدست آوردیم دیگر نیاز نیست در سازنده Person این بررسی انجام شود ؟ یعنی این Logic مربوط به Application هست ؟ معتبر بودن Country در Person چک نشود ؟

    مرسی

    • هادی احمدی

      بهتر است در سازنده ی Person، مقدار داشتن Country هم چک شود و Application Service فقط مسئول گرفتن داده ها از دیتابیس و دادن آن به Domain باشد.

      موفق باشید

  9. ممنون استاد از اینکه وقت میزارید برای پاشخ

    آرزوی سلامتی دارم براتون

  10. سلام آقا هادی
    از مطالب بسیار خوبتان متشکرم
    می خواستم اگر لطف کنید یک کتاب راحت برای فهمیدن مفاهیم DDD پیشنهاد دهیدو اگر لینکی دارید که پروژه یا مثال های DDD را با C# پیاده سازی کرده معرفی کنید.
    خیلی ممنون

  11. با سلام و احترام.ضمن تشکر از مطالب مفیدی که توضیح دادین.جناب مهندس من یک سوال دارم در مورد repository در این مبحث.جایی خوندم که repository برای جدا کردن “لایه دسترسی به داده” از “دومین مدل” هستش و عملیات crud رو روی دیتا بیس انجام میده.اما در بیشتر پروژه هایی که میبینم از repository استفاده نشده.میخواستم بدونم دقیقا چه زمانی ازش استفاده میشه و آیا جایگزینی براش وجود داره ؟ متشکرم

    • هادی احمدی

      با سلام

      همانطور که خودتون فرمودید Repository جهت جداسازی مکانیزم های ذخیره سازی از Domain Model مورد استفاده قرار میگیرد. تعجب میکنم از اینکه میفرمایید در بیشتر پروژه ها از این الگو استفاده نشده. در DDD این الگو برای بازیابی و همچنین ذخیره سازی Aggregate ها پیشنهاد می شود و همچنین Practice هایی زیادی هم در مورد پیاده سازی صحیح آن وجود دارد. تقریبا یک بخش کامل در هرکدام از کتاب های DDD در مورد این الگو وجود دارد. می توانید برای اطلاعات بیشتر منابع را مطالعه بفرمایید.

  12. سلام
    مطالب واقعا عالی و روان توضیح داده شده اند. کمک زیادی به بنده کردن، منتظر مطالب بعدی هستیم.
    با تشکر فراوان

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

  14. با عرض سلام.
    یه سوال در مورد cqrs داشتم، ما تو cqrs یه دیتا بیس event داریم و چند تا دیتا بیس read . اگه هنگام بروزرسانی دیتا بیس های read بعد از event store خطا رخ بده، عملا تغییرات event Store دیگه rollback نمی شه . می خواستم ببینم برا این سناریو راه کاری وجود داره ؟ یا مثلا اگه اخواهیم وسط پروژه فیلدی به یک entity اضافه کنیم نحوه اعمال این تغییرات تو read مدل ها چطوری می شه . ممنون از راهنمایی تون

    • هادی احمدی

      سلام محمد جان

      در مورد سوال اول باید عرض کنم دلیلی برای Rollback کردن Event store وجود ندارد. وقتی یک Event درون Event Store (یا بهتر بگم Write Model) شما ذخیره می شود به این معناست که این Command پردازش شده و تمام شده است. بنابراین درخواست کاربر انجام شده است. از انجا که Update شدن Read Model به صورت Eventual انجام خواهد گرفت (برای مثال توسط یک Bus و با کمک یک Message Queue)، دلیلی ندارد اقدام به Rollback کردن تراکنش ها Write Model کنید. در صورتی که بروزرسانی Read Model با خطا مواجه شود، توسط Bus مجددا Retry می شود. این کار به دفعات انجام می شود تا بالاخره Read Model بروزرسانی شود.

      سوال دوم شما مربوط به موضوع Versioning در Event Sourcing می شود که بحث طولانی هست. برای مطالعه روی این بحث میتونید به کتاب Versioning in an Event Sourced System نوشته ی Greg Young مراجعه بفرمایید. این کتاب به صورت رایگان در لینک زیر قابل دسترس می باشد :

      https://leanpub.com/esversioning/read

      موفق باشید

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

    • هادی احمدی

      سلام پوریا جان
      خوشحالم که مطالب و مقاله ها تونستن کمکتون کنند.

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

  16. سلام مهندس جان

    Infrastructure Layer
    تمام زیر ساخت های داده ای و تکنولوژی محور نرم افزار در این لایه پیاده سازی می شوند. دسترسی به داده ها (Data Access)، دسترسی به وب سرویس های متفرقه (مانند ارسال پیامک و …) و همچنین زیر ساخت های Cross-Cutting (مانند Logging، Caching و … ) در این لایه پیاده سازی می شوند.

    با توجه به تعریف بالا

    EF CONTEXT و یا Dapper هم در این لایه قرار می گیره ؟

  17. سلام مجدد مهندس جان

    Infrastructure Layer با Infrastructure Service یکی هست ؟

    طبق این لینک

    https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design

    repository در لایه Infrastructure قرار میگیرد ؟

    • هادی احمدی

      سلام محمد جان

      نخیر متفاوت هستند، سرویس هایی که کارهای زیرساختی انجام می دهند Infrastructure Service نام دارند ولی Infrastructure Layer یک لایه هست. در واقع پیاده سازی Infrastructure Service ها در لایه ی Infrastructure قرار دارند.

      اگر منظور از Repository، پیاده سازی اونهاست (و نه اینترفیس ها)، بله در لایه ی Infrastructure قرار میگیرد.

دادن پاسخ بهمصطفی بی خیال پاسخ!

آدرس ایمیلتان منتشر نمیشودگزینه های الزامی ستاره دار شده اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

رفتن به بالا