Domain Driven Design Summary

Setup-Fixture-Teardown
Dictionary

DDD  برای نرم افزارهایی با پیچیدگی های زیاد نه صرفاً بزرگ.

DDD معماری نیست ، یک روش الگوی طراحی می باشد،برای مدیریت پیچیدگی ها و توسعه و نگهداری سیستم. که این پیچیدگی ها مربوط به Domain (کسب و کار و یا بیزینس ما)  هستش.

Domain : کسب و کار و یا بیزینس ما  ، مثلاً فروشگاه اینترنتی ما

BC یا Bounded Context : جدا کردن واحدهای مرتبط به هم ، مثل واحد فروش و فنی و پشتیبانی و…. که می توانند سرویس دهنده باشند و یا سرویس گیرنده.

Shared Kernel : نقطه مشترک بین دامنه ها (Domain)

Domain Expert : کسی که این حوزه و دامنه را کامل می شناسه.

Sub Domain : محصولاتی که می خوام به مشتری تحویل بدم :

Core : قسمتی از بیزینس هستش که منو از دیگران متمایز میکنه . پیچیدگی ها بیشتر در Core هستش. بیزینس برنامه نویسی یا مدیریت فرآیندهای کسب کار

General : مثلاً سیستم چت و… که بودنش نیازه ولی مزیتی برای من محسوب نمیشود.

Support:خدمات کم ارزش تر و ساده تر که باید باشند . افزودن و حذف کاربر | افزودن و حذف محصول و….

یک دیکشنری که زبان فنی (تیم فنی) را به زبان تحلیل گران کسب و کار ترجمه کند.

Entity : ساختاری که شناسه(Id) و رفتار(Behavior) و Property دارد و با عوض کردن ویژگی هاش ساختارش و مفهمش عوض نمیشه.

Value Object : شناسه ندارد | با عوض کردن هر جزئی از آن ساختار آن تغییر میکند.

aggregate :  به چند Entity که با هم ارتباط دارند یک aggregate   می گویند.

aggregate root : ارتباط بین aggregate ها با aggregate root صورت میگرد.

Anemic و Rich : هر کلاسی که فقط Property را شامل شود و هیچ سازنده (Constructor) و متدی (Method) نداشته باشد، Anemic Model نام دارد ، Rich Model نوعی کلاسی محسوب می‌شود که در آن Behavior ها و منطق بیزینس یک مدل وجود دارد.

Domain Service : کارها و شرط و شروط هایی که می خواهیم انجام دهیم.

Domain Event :مثلاً یک پیامک ارسال میکنیم ، یک پیامی به سیستم می فرستد و اعلام میکند که پیامکت ارسال شد.