Merge pull request #63 from iliya-fatahi/part1-chapter2-review

Full review of chapter two
mohammadKarimi · Apr 27, 2024 · ef9446c · ef9446c
2 parents a7b946b + 144091d
commit ef9446c
Show file tree

Hide file tree

Showing 8 changed files with 9 additions and 9 deletions.
diff --git a/...t/part 1 - Strategic Design/chapter 2/2.1 Business Problem/Business Problems.md b/...t/part 1 - Strategic Design/chapter 2/2.1 Business Problem/Business Problems.md
@@ -9,4 +9,4 @@ type: docs
 
 مشکلات کسب‌وکار همزمان در سطح دامنه کسب‌وکار و زیردامنه‌ها ظاهر می‌شوند. هدف یک شرکت ارائه راه‌حل برای مشکلات مشتریانش می باشد. به عنوان مثال به مورد دیجی کالا در فصل اول برگردیم، مشتریان این شرکت نیاز به ارسال بسته‌ها در زمان‌های محدود دارند، بنابراین شرکت در تلاش برای بهینه‌سازی فرآیند حمل و تسهیل در ارسال بسته هایش می باشد.
 
-زیردامنه‌ها در تفسیری دیگه یه جورایی دامنه‌های مشکلات شرکت هستند که هدف افراد ارائه راه حل هایی برای این دامنه های مشکلات هست. یک زیردامنه می تواند مدیریت فرآیند ذخیره و بازیابی اطلاعات به عهده بگیرد. یک زیردامنه دیگر میتواند فرآیند انجام تراکنش‌های مالی را بهینه‌سازی ‌کند. از سمت و سوی دیگر یک زیر دامنه میتواند عملیات حسب داری شرکت را عهده دار شود.
+زیردامنه‌ها در تفسیری دیگه یه جورایی دامنه‌های مشکلات شرکت هستند که هدف افراد ارائه راه حل هایی برای این دامنه های مشکلات هست. یک زیردامنه می تواند مدیریت فرآیند ذخیره و بازیابی اطلاعات به عهده بگیرد. یک زیردامنه دیگر میتواند فرآیند انجام تراکنش‌های مالی را بهینه‌سازی ‌کند. از سمت و سوی دیگر یک زیر دامنه میتواند عملیات حساب داری شرکت را عهده دار شود.
diff --git a/content/part 1 - Strategic Design/chapter 2/2.10 Conclusion/Conclusion.md b/content/part 1 - Strategic Design/chapter 2/2.10 Conclusion/Conclusion.md
@@ -12,6 +12,6 @@ type: docs
 
 برای اطمینان از ارتباط مؤثر، زبان فراگیر باید ابهامات و فرض‌های ضمنی را حذف کند. تمامی اصطلاحات یک زبان باید سازگار باشند؛ بدون اصطلاحات دوپهلو و بدون هیچگونه استفاده از اصطلاحات مترادف و هم معنی.
 
-پرورش یک زبان فراگیر یک فرآیند پیوسته و زمانبر است. بنابراین با تکامل پروژه، دانش بیشتری از دامنه کسب و کار کشف می‌شود. اما این اطلاعات باید در زبان فراگیر منعکس شوند تا بتوانیم پیشرفت و بهبود را در طراحی و توسعه نرم‌افزار ایجاد کنیم
+پرورش یک زبان فراگیر یک فرآیند پیوسته و زمانبر است. بنابراین با تکامل پروژه، دانش بیشتری از دامنه کسب و کار کشف می‌شود. اما این اطلاعات باید در زبان فراگیر منعکس شوند تا بتوانیم پیشرفت و بهبود را در طراحی و توسعه نرم‌افزار ایجاد کنیم.
 
 ابزارهایی مانند لغتنامه‌های مبتنی بر ویکی و تست‌های Gherkin می‌توانند به طور قابل توجهی در کاهش فرآیند مستندسازی و حفظ یک زبان فراگیر کمک کنند. با این حال، پیش‌نیاز اصلی برای یک زبان مؤثر استفاده مداوم از آن است: زبان باید به طور سیستماتیک در تمامی ارتباطات مرتبط با پروژه استفاده شود.
diff --git a/...t 1 - Strategic Design/chapter 2/2.2 Knowledge Discovery/Knowledge Discovery.md b/...t 1 - Strategic Design/chapter 2/2.2 Knowledge Discovery/Knowledge Discovery.md
@@ -6,7 +6,7 @@ type: docs
 
 ## کشف دانش
 
-برای طراحی یک راه‌حل نرم‌افزاری مؤثر، ما  باید حداقل یه دانش ابتدایی را از حوزه کسب و کار، درک کنیم. همانطور که در فصل 1 بحث کردیم، این دانش متعلق به متخصصان دامنه ی کسب و کار است: وظیفه آنها تخصص و درک تمام پیچیدگی‌های حوزه کسب و کار خودشان است. به هیچ وجه نباید ما، (نمی‌توانیم)، متخصصان آن حوزه کسب و کار شویم. با این حال، برای ما خیلی مهم است که متخصصان دامنه را درک کنیم و از همان اصطلاحات کسب و کاری و بیزینسی استفاده کنیم که آنها استفاده می‌کنند..
+برای طراحی یک راه‌حل نرم‌افزاری مؤثر، ما  باید حداقل یه دانش ابتدایی را از حوزه کسب و کار، درک کنیم. همانطور که در فصل 1 بحث کردیم، این دانش متعلق به متخصصان دامنه ی کسب و کار است: وظیفه آنها تخصص و درک تمام پیچیدگی‌های حوزه کسب و کار خودشان است. به هیچ وجه نباید ما، (نمی‌توانیم)، متخصصان آن حوزه کسب و کار شویم. با این حال، برای ما خیلی مهم است که متخصصان دامنه را درک کنیم و از همان اصطلاحات کسب و کاری و بیزینسی استفاده کنیم که آنها استفاده می‌کنند.
 
 برای اثربخش بودن یک نرم افزار، باید اون نرم‌افزار تا حد زیادی به شیوه‌ی تفکر متخصصان دامنه درباره مسئله - یعنی مدل‌های ذهنی آنها - شباهت زیادی داشته باشد. بدون درک از مسئله بیزینس و استدلال پشت نیازها، راه‌حل‌های ما محدود به "ترجمه" نیازهای بیزینس به سورس کد خواهند بود.  حالا اگر ما نیازمندی های خیلی مهم و حیاتی بیزینس را از دست بدیم، چه اتفاقی خواهد افتاد؟
 و یا اینکه نیازمندی هایی که ما بدست آورده ایم یک مفهوم بیزینسی را شرح ندهد، آن وقت چه اتفاقی خواهد افتاد؟

diff --git a/content/part 1 - Strategic Design/chapter 2/2.3 Communication/Communication.md b/content/part 1 - Strategic Design/chapter 2/2.3 Communication/Communication.md
@@ -6,15 +6,15 @@ type: docs
 
 ## ارتباطات
 
-با اطمینان می تونیم بگیم که تقریباً تمام پروژه‌های نرم‌افزاری نیاز به همکاری افراد در نقش‌های مختلف دارن: متخصص دامنه، مالکان محصول، مهندسان، طراحان رابط کاربری و تجربه کاربری، مدیران پروژه، تسترها، تحلیلگران و سایر افراد.
+با اطمینان می تونیم بگیم که تقریباً تمام پروژه‌های نرم‌افزاری نیاز به همکاری افراد در نقش‌های مختلف دارن: متخصص دامنه، مالکان محصول، مهندسان، طراحان رابط و تجربه کاربری، مدیران پروژه، تسترها، تحلیلگران و سایر افراد.
 مثل هر تلاش تیمیه دیگه ای، نتیجه ی کار کاملا به اندازه ی اینکه چقدر تمام این افراد می‌تونن با هم کار کنن، وابسته است. به عنوان مثال، آیا همه افراد موافقن که چه مساله ای در حال حل شدن هست؟ در مورد راه حلی که در حال ساختنش هستن چی؟ آیا افراد دارای فرضیات متفاوت و یا متضادی درباره نیازمندی‌های کارکردی و غیرکارکردی یه سیستم هستن؟ موافقت و هم راستا بودن در تمام فرایند مرتبط با پروژه،  برای موفقیت پروژه ضروری است.
 تحقیقات در زمینه علت‌های شکست پروژه‌های نرم‌افزاری نشون داده که ارتباط مؤثر برای به اشتراک گذاری دانش و موفقیت پروژه ضروریه. با این حال، با وجود اهمیت این موضوع، ارتباط مؤثر به ندرت در پروژه‌های نرم‌افزار مشاهده می‌شه. اغلب، ساید بیزینس و مهندس ها کمتر با یکدیگر تعامل مستقیم دارن. به جای این ارتباطات موثر، دانش دامنه از متخصصان دامنه به مهندسان از طریق افرادی انتقال پیدا میکنه که نقش واسطه یا "مترجم" رو بازی می‌کنن، از جمله تحلیلگرها و مدیران سیستم/کسب‌وکار، مالکان محصول و مدیران پروژه. جریان معمول به اشتراک گذاری دانش به وسیله این افراد در شکل 2-1 نمایش داده شده.
 ( این نکته رو هم بگم که ما نمیگیم که این نقش ها بی فایده هستند، ما در نحوه ی انتقال این دانش داریم صحبت میکنیم.)
 
 ![[Figure 2-1.png]]
 شکل 2-1. جریان به اشتراک گذاری دانش در یک پروژه نرم‌افزار
 
-در طول چرخه توسعه نرم‌افزار به روش های سنتی، دانش دامنه به شکلی که مهندسان آن را به راحتی بفهمند "ترجمه" می‌شه. این ترجمه مدل تجزیه و تحلیل نامیده می‌شه که به جای مفهومی از حوزه کسب و کار پشت آن، توصیفی از نیازهای سیستمه.
+در طول چرخه توسعه نرم‌افزار به روش های سنتی، دانش دامنه به شکلی که مهندسان آن را به راحتی بفهمند "ترجمه" می‌شه. این ترجمه مدل تجزیه و تحلیل نامیده می‌شه که **به جای مفهومی از حوزه کسب و کار پشت آن، توصیفی از نیازهای سیستمه.**
 هرچند  اهداف می تونن درست باشن، اما این واسطه‌گری ممکنه برای به اشتراک گذاری دانش خطرناک باشه. در هر ترجمه ای، اطلاعات از دست می‌ره؛ در این مورد، دانش دامنه، که برای حل مسائل بیزینس ضروریه، در مسیرش به سمت مهندسان نرم‌افزار از دست می‌ره.
 
 ![[Figure 2-1 1.png]]

diff --git a/...gn/chapter 2/2.4 What Is a Ubiquitous Language/What Is a Ubiquitous Language.md b/...gn/chapter 2/2.4 What Is a Ubiquitous Language/What Is a Ubiquitous Language.md
@@ -17,7 +17,7 @@ type: docs
 - تبدیل طراحی سیستم ها به کد
 
 به جای ترجمه مداوم دانش دامنه ی کسب و کار، طراحی مبتنی بر دامنه نیاز به یک زبانی برای توضیح دامنه کسب و کار دارد و اون زبان چیزی جز یک زبان فراگیر نیست.
-تمام افراد مرتبط با پروژه، از جمله مهندسان نرم‌افزار، مالکان محصول، متخصصان حوزه، طراحان رابط کاربری/تجربه کاربری رابط و تجربه ی کاربری، باید زبان فراگیر را در زمانی که دارند دامنه کسب و کار را توصیف میکنند، به کار بگیرند 
+تمام افراد مرتبط با پروژه، از جمله مهندسان نرم‌افزار، مالکان محصول، متخصصان حوزه، طراحان رابط/تجربه کاربری، باید زبان فراگیر را در زمانی که دارند دامنه کسب و کار را توصیف میکنند، به کار بگیرند. 
 
 بویژه متخصصان دامنه باید به راحتی بتوانند از این زبان فراگیر برای توصیف حوزه کسب و کار خود استفاده کنند؛ این زبان همچنین نمایانگر حوزه کسب و کار و مدل‌های ذهنی متخصصان دامنه خواهد بود.
 

diff --git a/...tegic Design/chapter 2/2.5 Language of the Business/2.5 Language of Business.md b/...tegic Design/chapter 2/2.5 Language of the Business/2.5 Language of Business.md
@@ -4,7 +4,7 @@ weight: 204
 type: docs
 ---
 
-## زبان کسب و کار و یا زبان بیزینس
+## زبان کسب و کار
 
 اهمیت این نکته را باید تأکید کرد که زبان فراگیر، زبان کسب و کار است. در نتیجه، در استفاده از این زبان باید فقط از اصطلاحات مرتبط با حوزه کسب و کار استفاده شود. هیچ اصطلاح فنی!
 آموزش به متخصصان حوزه کسب و کار در مورد مفاهیم singleton و abstract factory هدف شما نیست. هدف زبان فراگیر، فرم دادن به درک و مدل‌های ذهنی متخصصان حوزه کسب و کار است. چطور؟ با استفاده از اصطلاحاتی که به راحتی قابل درک هستند.

diff --git a/...2.6 Model of the Business Domain/2.6.2 Effective Modeling/Effective Modeling.md b/...2.6 Model of the Business Domain/2.6.2 Effective Modeling/Effective Modeling.md
@@ -12,5 +12,5 @@ type: docs
 
 در واقع یک مدل، یک انتزاع است. انتزاع به ما این امکان را می‌دهد که با حذف جزئیات غیرضروری و تنها باقی گذاشتن آنچه برای حل مسئله مورد نیاز است، با پیچیدگی مقابله کنیم.
 
-از سوی دیگر، یک انتزاع ناکارآمد اطلاعات لازم و ضروری را حذف می‌کند و یا با باقی گذاشتن اطلاعاتی که لازم نیست، نویز ایجاد می‌کند. همانطور که در مقاله "برنامه‌نویس متواضع" W. Dijkstra میتوانیم ببینیم که، هدف از انتزاع این نیست که ابهام را از بین ببرد بلکه برای ایجاد یک سطح معنایی جدید است که در آن می‌توان به طور کاملاً دقیق عمل کرد.
+از سوی دیگر، یک انتزاع ناکارآمد اطلاعات لازم و ضروری را حذف می‌کند و یا با باقی گذاشتن اطلاعاتی که لازم نیست، نویز ایجاد می‌کند. همانطور که در مقاله "برنامه‌نویس متواضع" W. Dijkstra میتوانیم ببینیم که، هدف از انتزاع این نیست که **ابهام** را از بین ببرد بلکه برای ایجاد یک **سطح معنایی** جدید است که در آن می‌توان به طور کاملاً دقیق عمل کرد.
 
diff --git a/...ness Domain/2.6.3 Modeling the Business Domain/Modeling the Business Domain.md b/...ness Domain/2.6.3 Modeling the Business Domain/Modeling the Business Domain.md
@@ -9,4 +9,4 @@ type: docs
 هنگامی که یک زبان فراگیر را ایجاد می کنیم، در واقع داریم یک مدل از دامنه بیزینس را ایجاد می‌کنیم. این مدل باید مدل‌های ذهنی متخصصان دامنه را به تصویر بکشد - فرآیند‌های فکری آن‌ها را در مورد اینکه چگونه بیزینس کار می‌کند تا وظایف خود را اجرا کند، پیاده‌سازی کند. مدل باید موجودیت‌های بیزینس و رفتار آن‌ها، روابط علت و معلول و قوانین را بازتاب بدهد.
 زبان فراگیری که ما استفاده می‌کنیم قرار نیست هر جزئیات ممکنی از دامنه را پوشش دهد. به جای آن، مدل باید شامل جنبه‌های کافی از دامنه بیزینس باشد تا امکان پیاده‌سازی سیستم مورد نیاز را فراهم کند؛
 در فصلهای بعدی، خواهید دید که زبان فراگیر چگونه می‌تواند تصمیمات طراحی و پیاده‌سازی سطح پایین را هدایت کند.
-ارتباط مؤثر بین تیم‌های مهندسی و متخصصان دامنه بسیار حیاتی است. اهمیت این ارتباط با افزایش پیچیدگی دامنه بیزینس افزایش می‌یابد. هر چه دامنه بیزینس پیچیده‌تر باشد، مدل کردن و پیاده‌سازی منطق بیزینس آن در کد دشوارتر خواهد بود. حتی یک سوءتفاهم کوچک نسبت به یک دامنه بیزینس پیچیده یا اصول پایه ای آن، به طور ناخواسته منجر به پیاده‌سازی‌های اشتباهای و همچنینی ایجاد خطاهای جدی خواهد شد. تنها راه قابل اعتماد برای اطمینان از درک یک دامنه بیزینس، ارتباط و مکالمه با متخصصان دامنه و انجام آن به زبانی که آن‌ها درک می‌کنند، یعنی زبان بیزینس، است.
+ارتباط مؤثر بین تیم‌های مهندسی و متخصصان دامنه بسیار حیاتی است. اهمیت این ارتباط با افزایش پیچیدگی دامنه بیزینس افزایش می‌یابد. هر چه دامنه بیزینس پیچیده‌تر باشد، مدل کردن و پیاده‌سازی منطق بیزینس آن در کد دشوارتر خواهد بود. حتی یک سوءتفاهم کوچک نسبت به یک دامنه بیزینس پیچیده یا اصول پایه ای آن، به طور ناخواسته منجر به پیاده‌سازی‌های اشتباهی و همچنین ایجاد خطاهای جدی خواهد شد. تنها راه قابل اعتماد برای اطمینان از درک یک دامنه بیزینس، ارتباط و مکالمه با متخصصان دامنه و انجام آن به زبانی که آن‌ها درک می‌کنند، یعنی زبان بیزینس، است.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -9,4 +9,4 @@ type: docs

		مشکلات کسب‌وکار همزمان در سطح دامنه کسب‌وکار و زیردامنه‌ها ظاهر می‌شوند. هدف یک شرکت ارائه راه‌حل برای مشکلات مشتریانش می باشد. به عنوان مثال به مورد دیجی کالا در فصل اول برگردیم، مشتریان این شرکت نیاز به ارسال بسته‌ها در زمان‌های محدود دارند، بنابراین شرکت در تلاش برای بهینه‌سازی فرآیند حمل و تسهیل در ارسال بسته هایش می باشد.

		زیردامنه‌ها در تفسیری دیگه یه جورایی دامنه‌های مشکلات شرکت هستند که هدف افراد ارائه راه حل هایی برای این دامنه های مشکلات هست. یک زیردامنه می تواند مدیریت فرآیند ذخیره و بازیابی اطلاعات به عهده بگیرد. یک زیردامنه دیگر میتواند فرآیند انجام تراکنش‌های مالی را بهینه‌سازی ‌کند. از سمت و سوی دیگر یک زیر دامنه میتواند عملیات حسب داری شرکت را عهده دار شود.
		زیردامنه‌ها در تفسیری دیگه یه جورایی دامنه‌های مشکلات شرکت هستند که هدف افراد ارائه راه حل هایی برای این دامنه های مشکلات هست. یک زیردامنه می تواند مدیریت فرآیند ذخیره و بازیابی اطلاعات به عهده بگیرد. یک زیردامنه دیگر میتواند فرآیند انجام تراکنش‌های مالی را بهینه‌سازی ‌کند. از سمت و سوی دیگر یک زیر دامنه میتواند عملیات حساب داری شرکت را عهده دار شود.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -12,5 +12,5 @@ type: docs

		در واقع یک مدل، یک انتزاع است. انتزاع به ما این امکان را می‌دهد که با حذف جزئیات غیرضروری و تنها باقی گذاشتن آنچه برای حل مسئله مورد نیاز است، با پیچیدگی مقابله کنیم.

		از سوی دیگر، یک انتزاع ناکارآمد اطلاعات لازم و ضروری را حذف می‌کند و یا با باقی گذاشتن اطلاعاتی که لازم نیست، نویز ایجاد می‌کند. همانطور که در مقاله "برنامه‌نویس متواضع" W. Dijkstra میتوانیم ببینیم که، هدف از انتزاع این نیست که ابهام را از بین ببرد بلکه برای ایجاد یک سطح معنایی جدید است که در آن می‌توان به طور کاملاً دقیق عمل کرد.
		از سوی دیگر، یک انتزاع ناکارآمد اطلاعات لازم و ضروری را حذف می‌کند و یا با باقی گذاشتن اطلاعاتی که لازم نیست، نویز ایجاد می‌کند. همانطور که در مقاله "برنامه‌نویس متواضع" W. Dijkstra میتوانیم ببینیم که، هدف از انتزاع این نیست که ابهام را از بین ببرد بلکه برای ایجاد یک سطح معنایی جدید است که در آن می‌توان به طور کاملاً دقیق عمل کرد.