Forwarded from FullstacksJS — Academy
قسمت چهارم ماب ریویو: معماری نرم افزار و DDD
تو این جلسه یک پروژه NestJS رو با هم ریویو میکنیم.
مشاهده ویدئو
اگر علاقه دارید میتونید کدهاتون رو برای من بفرستید تا توی این جلسهها با همدیگه ریویوشون کنیم.
مباحث
00:00 ماب ریویو چیه؟
01:06 درباره پروژه؟
02:32 پارادایم Reactive Programming
03:55 معماری های Hexagonal
05:39 تعریف و انواع وابستگی توی معماری
06:55 مفهوم Dependency Inversion
13:41 مفهوم Dependency Injection
17:35 استفاده این مفاهیم توی معماری
20:08 لایه Domain توی معماری Clean
21:10 مزیت نام گذاری روی معماریها و پترنها
21:57 Domain Driven Design چیه؟
34:24 معرفی منابع برای DDD
37:53 پرکیتس ها و اهمیت Communication
42:39 مسئولیت لایه Application
44:43 آنتی پرتن Anemic domain
46:48 مفهوم Ubiquitous language و Bounded Context
53:16 مفاهیم Strategic design و Tactical Design
54:29 فرق بین Value Object و Entity
1:00:42 مفهوم Domain Event
1:02:00 مفهوم Aggregate root
1:05:34 استفاده از این مفاهیم تو NestJS
1:06:53 مفهوم persistence ignorance
1:09:06 بی اهمیت بودن ابزارها و اهمیت نیاز بیزینس
1:12:03 چرا مقایسه ابزارها درست نیست
1:14:29 کجا باید از DDD استفاده کنیم؟
1:15:41 چرا کسب تجربه توی DDD سخته؟
1:16:34 پترن CQRS
1:19:26 چرا نباید همه جا از پترنها و معماریها استفاده کنیم؟
✦ ماب ریویو چیه؟
✦ سورس کد
✦ اضافه کردن به تقویم
#mobreview #nestjs #cqrs #designpatterns #ddd #cleanarchitecture #hexagonarchitecture #mongodb #typescript #nodejs
تو این جلسه یک پروژه NestJS رو با هم ریویو میکنیم.
مشاهده ویدئو
اگر علاقه دارید میتونید کدهاتون رو برای من بفرستید تا توی این جلسهها با همدیگه ریویوشون کنیم.
مباحث
00:00 ماب ریویو چیه؟
01:06 درباره پروژه؟
02:32 پارادایم Reactive Programming
03:55 معماری های Hexagonal
05:39 تعریف و انواع وابستگی توی معماری
06:55 مفهوم Dependency Inversion
13:41 مفهوم Dependency Injection
17:35 استفاده این مفاهیم توی معماری
20:08 لایه Domain توی معماری Clean
21:10 مزیت نام گذاری روی معماریها و پترنها
21:57 Domain Driven Design چیه؟
34:24 معرفی منابع برای DDD
37:53 پرکیتس ها و اهمیت Communication
42:39 مسئولیت لایه Application
44:43 آنتی پرتن Anemic domain
46:48 مفهوم Ubiquitous language و Bounded Context
53:16 مفاهیم Strategic design و Tactical Design
54:29 فرق بین Value Object و Entity
1:00:42 مفهوم Domain Event
1:02:00 مفهوم Aggregate root
1:05:34 استفاده از این مفاهیم تو NestJS
1:06:53 مفهوم persistence ignorance
1:09:06 بی اهمیت بودن ابزارها و اهمیت نیاز بیزینس
1:12:03 چرا مقایسه ابزارها درست نیست
1:14:29 کجا باید از DDD استفاده کنیم؟
1:15:41 چرا کسب تجربه توی DDD سخته؟
1:16:34 پترن CQRS
1:19:26 چرا نباید همه جا از پترنها و معماریها استفاده کنیم؟
✦ ماب ریویو چیه؟
✦ سورس کد
✦ اضافه کردن به تقویم
#mobreview #nestjs #cqrs #designpatterns #ddd #cleanarchitecture #hexagonarchitecture #mongodb #typescript #nodejs
YouTube
Mob Review 4: معماری نرم افزار و DDD
توی این جلسه یک پروژه تو این جلسه یک پروژه NestJS رو با هم ریویو میکنیم.
درباره ماب ریویو:
ماب ریویو یه رویداد دوستانه و خودمونی برای انتقال تجربه دانشه.
توی این رویداد دور هم جمع میشیم تا یک سورس کد رو با هم ریویو کنیم و درباره پرکتیسهای بهتر و دلایلش…
درباره ماب ریویو:
ماب ریویو یه رویداد دوستانه و خودمونی برای انتقال تجربه دانشه.
توی این رویداد دور هم جمع میشیم تا یک سورس کد رو با هم ریویو کنیم و درباره پرکتیسهای بهتر و دلایلش…
Forwarded from Gopher Academy
🔵 عنوان مقاله
Using Go Channels to Solve Interface Impedance Mismatch
🟢 خلاصه مقاله:
استفاده از Go Channels برای رفع ناسازگاری بین رابطها
این یادداشت نشان میدهد که چگونه میتوان از Go Channels نه برای همزمانی، بلکه بهعنوان یک لایه تطبیق سبک استفاده کرد. Zach Musgrave توضیح میدهد که در مواجهه با “interface impedance mismatch”—جایی که یک API داده را بهصورت push میدهد و دیگری آن را بهصورت pull مصرف میکند، یا یکی جریانمحور است و دیگری تکرارشونده—یک Channel میتواند بهعنوان بافری خنثی، این دو جهان را بدون تغییرات اساسی در کد به هم متصل کند. در این الگو، تولیدکننده در همان جریان اجرای عادی دادهها را داخل Channel میگذارد و مصرفکننده با الگوی خواندن رایج از روی Channel آنها را برمیدارد؛ نیازی به goroutine یا معماری همزمانی پیچیده نیست. مزیتها شامل جداسازی بهتر، سادهسازی تبدیل بین رابطها، و تستپذیری بالاتر است؛ با این احتیاطها که اندازه بافر معقول انتخاب شود و استفاده غیرهمزمانی از Channel بهوضوح مستند گردد. پیام اصلی: Channels فقط برای همزمانی نیستند؛ آنها یک واسط ترکیبی مفید برای آشتی دادن APIها—بهویژه در تبدیل push/pull و جریان/تکرار—هستند.
#Go #Golang #Channels #APIDesign #InterfaceImpedanceMismatch #SoftwareEngineering #DesignPatterns #GoTips
🟣لینک مقاله:
https://golangweekly.com/link/174421/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Using Go Channels to Solve Interface Impedance Mismatch
🟢 خلاصه مقاله:
استفاده از Go Channels برای رفع ناسازگاری بین رابطها
این یادداشت نشان میدهد که چگونه میتوان از Go Channels نه برای همزمانی، بلکه بهعنوان یک لایه تطبیق سبک استفاده کرد. Zach Musgrave توضیح میدهد که در مواجهه با “interface impedance mismatch”—جایی که یک API داده را بهصورت push میدهد و دیگری آن را بهصورت pull مصرف میکند، یا یکی جریانمحور است و دیگری تکرارشونده—یک Channel میتواند بهعنوان بافری خنثی، این دو جهان را بدون تغییرات اساسی در کد به هم متصل کند. در این الگو، تولیدکننده در همان جریان اجرای عادی دادهها را داخل Channel میگذارد و مصرفکننده با الگوی خواندن رایج از روی Channel آنها را برمیدارد؛ نیازی به goroutine یا معماری همزمانی پیچیده نیست. مزیتها شامل جداسازی بهتر، سادهسازی تبدیل بین رابطها، و تستپذیری بالاتر است؛ با این احتیاطها که اندازه بافر معقول انتخاب شود و استفاده غیرهمزمانی از Channel بهوضوح مستند گردد. پیام اصلی: Channels فقط برای همزمانی نیستند؛ آنها یک واسط ترکیبی مفید برای آشتی دادن APIها—بهویژه در تبدیل push/pull و جریان/تکرار—هستند.
#Go #Golang #Channels #APIDesign #InterfaceImpedanceMismatch #SoftwareEngineering #DesignPatterns #GoTips
🟣لینک مقاله:
https://golangweekly.com/link/174421/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Dolthub
Go channels to solve interface impedance mismatch
Learn how Go channels can solve a particular form of interface mismatch common in application development.