معماری نرم افزار (Onion Architecture) - بخش سوم

ساختار پروژه در معماری onion

• Application Core (appli​cation + domain)
• Presen​tation
• Infras​tru​cure
• Tests

1. Core Layer

• Domain

در این لایه ما هیچ تعامل مستقیمی با لایه‌های بیرونی نداریم. domain business و domain logicدر این لایه مشاهده می شوند. ساختاری چون entities, value objects, events, exceptions, services, factories interfaces پیاده سازی می گردند.

• Application

لایه application منطق internal domain را مدیریت می کند ، از رو این لایه امکان ارتباط بین لایه داخلی و لایه های بیرونی مانند لایه presentation، tests و infrastructure را فراهم می کند.

2. Presentation Layer

در این لایه پیاده سازی نهایی داده دریافتی از لایه داخلی برای کاربر نهایی از طریق مدل های مختلف شامل وب، api ،console و غیره را امکان پذیر می باشد.

3. Infras​tru​cure layer

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

4. Test layer

لایه تست عملکرد application core و ارتباطات بین application core و outer layer‌ها را تست می کند.

در پیاده سازی این معماری از الگو CQRS استفاده خواهیم کرد . CQRS مخفف Command and Query Responsibility Segregation است، الگویی که عملیات خواندن و به روز رسانی را برای یک ذخیره داده جدا می کند. پیاده سازی CQRS در این معماری می تواند عملکرد، مقیاس پذیری و امنیت را به حداکثر برساند. همچنین انعطاف‌پذیری ایجاد شده توسط CQRS به سیستم اجازه می‌دهد در گذر زمان و با توسعه پروژه راحتر maintain شود (این نکته که در بخش اول به آن اشاره کردیم یکی از اساسی ترین اهداف ما برای داشتن یک معماری تمیز بود ) و از ایجاد تداخل در سطح دامنه توسط دستورات به‌روزرسانی جلوگیری می‌کند. بر همین اساس ما در لایه core فولدرهای مشابهی چون command، query و event ها را می بینیم.این فولدرها در دامنه برای ایجاد رویداد و در application پیاده سازی handler به ازای هر رویداد استفاده خواهد شد.

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

Application Core (application + domain)

Application

• Event:

رویداد های ایجاد شده در لایه دامنه در این مدیریت می گردند. مثلا ارسال ایمیل بعد از ثبت یک سفارش جدید

• services:

سرویس‌ها وظیفه‌ی تعامل بین دامنه ای را با استفاده از ‌interfaceهای تعریف شده در لایه دامنه امکان پذیر می سازند. مثلا دریافت لیست سفارش های یک کاربر (در نظر داشته باشید که کاربر و سفارش دو دامنه جدا می باشند)

• Query:

کویری ها وظیفه واکشی داده از دامنه های اصلی از طریق interface های پیاده سازی شده در لایه های بیرونی را برعهده دارد. مثلا دریافت لیست اخرین سفارش ها بر اساس بازه زمانی

• command :

در این لایه command‌هایی برای تغییر وضعیت business domain تعریف خواهد شد.مثلا ساخت یه سفارش جدید ، اپدیت وضعیت یک سفارش و غیره

Domain

• Model:

در این پوشه entity ها ، value objectها و aggregate‌ها قرار می گیرند

• Repository Interface:

در این پوشه interface‌هایی برای دسترسی به Business models در لایه های بیرونی قرار می‌گیرند. مثلا اینترفیسی برای دامنه سفارش

• Assertions :

اعتبارسنجی های مختلف برای value object در این پوشه پیاده سازی می گردند

• Service domain:

در این لایه ارتباطات داخلی پیچیده بین مدل های دامنه تعریف می گردند.

• Event:

در این پوشه رویداد هایی تعریف خواهند شدکه قصد تغییر وضعیت آنها بعد از یک command خاص در لایه business model را داریم

Presentation

• Controller
• DTO (Data Transfer Object)

Infrastructure

• ORM
• Dependency injection
• Repository implementations
• Filesystem
• Queue
• Cron-jobs
• Logging

Tests

• Unit Tests
• Integration
• Functional

این پست ادامه دارد ...

منابع بخش دوم:
clean architecture book
ThinkToCode

https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs