شروعی برای یادگیری طراحی با محوریت دامنه

1 پیشگفتاری از Abel Avramاز DDDاولین بار در مورد طراحی Domain Driven شنیدم و اریک ایوانز را در یک گردهمایی کوچک از معماران در یک اجلاس کوهستانی که توسط بروس ایکل در تابستان 2005 سازماندهی شده بود ملاقات کردم. در این اجلاس تعدادی از افراد مورد احترام من شرکت کردند، از جمله مارتین فاولر، راد جانسون، کامرون. پردی، رندی استافورد و گرگور هوپ.به نظر می رسید این گروه کاملاً تحت تأثیر دیدگاه طراحی Domain Drivenقرار گرفته است و مشتاق کسب اطلاعات بیشتر در مورد آن بودند. همچنین این احساس را داشتم که همه آرزو می‌کردند که این مفاهیم بیشتر در جریان اصلی قرار بگیرند. وقتی متوجه شدم که اریک چگونه از مدل دامنه برای بحث در مورد راه‌حل‌هایی برای چالش‌های فنی مختلف مورد بحث گروه استفاده می‌کند، و چقدر بر حوزه کسب‌وکار به‌جای تبلیغات ویژه فناوری تأکید می‌کند، بلافاصله فهمیدم که این دیدگاهی است که جامعه به شدت نیاز دارد.ما، در جامعه توسعه سازمانی، به‌ویژه جامعه توسعه وب، سال‌ها با هیاهویی که ما را از توسعه نرم‌افزار شی گرا مناسب دور کرد، آلوده شده‌ایم. در جامعه جاوا، مدل‌سازی دامنه خوب در هیاهوی EJB و مدل‌های کانتینر/کامپوننت سال‌های 1999-2004 از بین رفت. خوشبختانه، تغییرات در فناوری و تجربیات جمعی جامعه توسعه نرم افزار ما را به سمت پارادایم های شی گرا سنتی سوق می دهد. با این حال، جامعه فاقد دیدگاه روشنی برای نحوه اعمال شی گرایی در مقیاس سازمانی است، به همین دلیل است که فکر می کنم DDDمهم است.2 معرفینرم افزار ابزاری است که به ما کمک می کند تا با پیچیدگی های زندگی مدرن خود مقابله کنیم. نرم افزار فقط وسیله ای برای رسیدن به هدف است و معمولاً این هدف چیزی بسیار عملی و واقعی است. به عنوان مثال، ما از نرم افزاری برای کنترل ترافیک هوایی استفاده می کنیم و این ارتباط مستقیمی با دنیای اطراف ما دارد. ما می‌خواهیم از مکانی به مکان دیگر پرواز کنیم، و این کار را با استفاده از ماشین‌آلات پیشرفته انجام می‌دهیم، بنابراین نرم‌افزاری را برای هماهنگ کردن پرواز هزاران هواپیما که در هر زمان در هوا هستند ایجاد می‌کنیم.نرم افزار باید کاربردی و مفید باشد. در غیر این صورت ما زمان و منابع زیادی را برای ایجاد آن سرمایه گذاری نمی کنیم. این باعث می شود که آن را به جنبه خاصی از زندگی ما بسیار مرتبط کند. یک بسته نرم افزار مفید را نمی توان از آن حوزه واقعیت جدا کرد، دامنه ای که قرار است به ما در مدیریت آن کمک کند. برعکس، نرم افزار عمیقاً با آن درگیر شده است.طراحی نرم افزار یک هنر است و مانند هر هنری نمی توان آن را به عنوان یک علم دقیق و با قضایا و فرمول ها آموخت و آموخت. ما می‌توانیم اصول و تکنیک‌هایی را کشف کنیم که برای استفاده در طول فرآیند ایجاد نرم‌افزار مفید هستند، اما احتمالاً هرگز نخواهیم توانست مسیر دقیقی را برای دنبال کردن از نیاز دنیای واقعی به ماژول کدی که برای پاسخگویی به آن نیاز است، ارائه دهیم. مانند یک تصویر یا یک ساختمان، یک محصول نرم افزاری شامل لمس شخصی کسانی است که آن را طراحی و توسعه داده اند، چیزی از جذابیت و استعداد (یا فقدان آن) کسانی که در پیدایش و رشد آن سهیم بوده اند.روش های مختلفی برای رویکرد طراحی نرم افزار وجود دارد. در 20 سال گذشته، صنعت نرم افزار روش های مختلفی را برای ایجاد محصولات خود می شناسد و از آنها استفاده می کند که هر کدام مزایا و معایب خود را دارند. هدف این نوشته تمرکز بر روش طراحی است که در دو دهه اخیر ظهور و تکامل یافته است، اما در چند سال اخیر به وضوح تبلور یافته است: طراحی دامنه محور. اریک ایوانز با نوشتن در یک کتاب بسیاری از دانش انباشته شده در مورد طراحی دامنه محور کمک زیادی به این موضوع کرده است. برای ارائه دقیق‌تر این موضوع، توصیه می‌کنیم کتاب «طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم‌افزار»، منتشر شده توسط Addison-Wesley، ISBN: 0-321-12521-5 را مطالعه کنید.بسیاری از بینش‌های ارزشمند را نیز می‌توان با دنبال کردن گروه بحث طراحی Domain Driven در:http://groups.yahoo.com/group/domaindrivendesignاین نوشته تنها مقدمه‌ای برای موضوع است و قصد دارد به سرعت درک اساسی، اما نه جزئی از طراحی دامنه را به شما بدهد. من فقط می خواهم اشتیاق شما را برای طراحی نرم افزار خوب با اصول و دستورالعمل های مورد استفاده در دنیای طراحی دامنه محور باز کنم.3 طراحی بر مبنای دامنه یا طراحی دامنه محور چیست؟توسعه نرم افزاری اغلب برای خودکارسازی فرآیندهایی که در دنیای واقعی وجود دارند، یا ارائه راه حل هایی برای مشکلات کسب و کار استفاده می شود. فرآیندهای کسب و کار خودکار شده‌اند یا مشکلات جهان واقعی که نرم افزار راه حلی برای دامنه‌ای از مشکلات است. ما باید از ابتدا درک کنیم که نرم افزار از این حوزه نشات گرفته و عمیقاً با آن مرتبط است.نرم افزار از کد تشکیل شده است. ممکن است وسوسه شویم که زمان زیادی را با کد صرف کنیم و نرم افزار را صرفاً به عنوان اشیا و روش ببینیم.خودروسازی را به عنوان یک استعاره در نظر بگیرید. کارگرانی که در ساخت خودرو فعالیت می کنند ممکن است در تولید قطعات خودرو تخصص داشته باشند، اما در انجام این کار اغلب دید محدودی از کل فرآیند تولید خودرو دارند. آنها شروع به نگاه کردن به ماشین به عنوان مجموعه عظیمی از قطعات می کنند که باید در کنار هم قرار گیرند، اما یک ماشین بسیار بیشتر از این است. یک ماشین خوب با یک دید شروع می شود. با مشخصات دقیق نوشته شده شروع می شود. و با طراحی ادامه می یابد. طراحی زیاد و زیاد. ماه ها، شاید سال ها زمان صرف طراحی، تغییر و اصلاح آن تا زمانی که به کمال برسد، تا زمانی که چشم انداز اصلی را منعکس کند. طراحی، پردازش همه‌ی اجزا بر روی کاغذ نیست. بخش اعظمی از آن شامل انجام مدل‌های خودرو و آزمایش آن‌ها در شرایط خاص است تا ببینیم آیا کار می‌کنند یا خیر. طراحی بر اساس نتایج آزمایش اصلاح شده است. خودرو در نهایت به تولید ارسال می شود و قطعات با هم ساخته و مونتاژ می شوند.توسعه نرم افزار نیز مشابه است. ما نمی توانیم فقط بنشینیم و کد را تایپ کنیم. ما می‌توانیم این کار را انجام دهیم، و برای موارد بی‌اهمیت به خوبی کار می‌کند. اما ما نمی توانیم نرم افزار پیچیده ای مانند آن ایجاد کنیم.برای ایجاد نرم افزار خوب، باید بدانید که آن نرم افزار چیست. شما نمی توانید یک سیستم نرم افزاری بانکی ایجاد کنید مگر اینکه درک خوبی از چیستی بانکداری داشته باشید، باید حوزه بانکداری را درک کنید.آیا می توان نرم افزار پیچیده بانکی را بدون دانش خوب حوزه ایجاد کرد؟ به هیچ وجه. هرگز.چه کسی بانکداری می داند؟ معمار نرم افزار؟ نه. او فقط از بانک استفاده می‌کند تا پول‌هایش را ایمن نگه دارد و در صورت نیاز در دسترس باشد.تحلیلگر نرم افزار؟ نه واقعا. او می داند که یک موضوع مشخص را تجزیه و تحلیل کند، زمانی که همه مواد لازم به او داده می شود.توسعه دهنده؟ فراموشش کن. پس کی؟ البته بانکداران سیستم بانکی را کارکنان داخل و متخصصان آنها به خوبی درک می کنند. آنها همه جزئیات، همه چیزها، همه مسائل احتمالی، همه قوانین را می دانند. این جایی است که ما همیشه باید شروع کنیم: دامنه.هنگامی که یک پروژه نرم افزاری را شروع می کنیم، باید روی دامنه ای که در آن فعالیت می کند تمرکز کنیم. تمام هدف نرم افزار ارتقاء یک دامنه خاص است. برای انجام این کار، نرم افزار باید با دامنه ای که برای آن ایجاد شده است هماهنگ باشد. در غیر این صورت فشار وارد دامنه خواهد شد و باعث اختلال در عملکرد، آسیب و حتی ایجاد هرج و مرج می شود.چگونه می توانیم نرم افزار را با دامنه هماهنگ کنیم؟ بهترین راه برای انجام این کار این است که نرم افزار را بازتابی از دامنه کنید. نرم افزار باید مفاهیم و عناصر اصلی دامنه را در خود بگنجاند و روابط بین آنها را دقیقاً درک کند. نرم افزار باید دامنه را مدل کند.کسی که دانش بانکی ندارد باید بتواند فقط با خواندن کد در یک مدل دامنه، چیزهای زیادی یاد بگیرد. این ضروری است. نرم‌افزارهایی که ریشه‌های عمیقی در دامنه ندارند، در طول زمان به تغییرات واکنش خوبی نشان نمی‌دهند.بنابراین ما با دامنه شروع می کنیم. بعد چی؟ دامنه چیزی از این دنیاست. فقط نمی توان آن را گرفت و روی صفحه کلید داخل رایانه ریخت تا به کد تبدیل شود. ما باید یک انتزاع از دامنه ایجاد کنیم. هنگام صحبت با کارشناسان دامنه، چیزهای زیادی در مورد یک دامنه می آموزیم. اما این دانش خام به راحتی به ساختارهای نرم افزاری تبدیل نمی شود، مگر اینکه انتزاعی از آن، طرحی در ذهن خود بسازیم.در ابتدا، طرح اولیه همیشه ناقص است. اما به مرور زمان در حین کار آن را بهتر می کنیم و برایمان بیشتر و بیشتر روشن می شود. این انتزاع چیست؟ این یک مدل است، یک مدل از دامنه.به گفته اریک ایوانز، مدل دامنه یک نمودار خاص نیست. این ایده ای است که نمودار قصد دارد آن را منتقل کند. این فقط دانش در سر یک متخصص حوزه نیست. این یک انتزاع دقیق و منتخب از آن دانش است. یک نمودار می تواند یک مدل را نشان دهد و ارتباط برقرار کند، همانطور که می تواند کدهایی را که با دقت نوشته شده است، و همچنین یک جمله انگلیسی.مدل، نمایش داخلی ما از دامنه هدف است و در طول طراحی و فرآیند توسعه بسیار ضروری است. در طول فرآیند طراحی، مدل را به خاطر می آوریم و ارجاعات زیادی به آن می کنیم. دنیای اطراف ما بیش از آن است که مغز ما بتواند آن را کنترل کند. حتی یک حوزه خاص می تواند بیش از آن باشد که یک ذهن انسان در یک زمان آن را مدیریت کند. ما باید اطلاعات را سازماندهی کنیم، آنها را نظام‌مند کنیم، آن‌ها را به قطعات کوچک‌تر تقسیم کنیم، آن‌ها را در ماژول‌های منطقی گروه‌بندی کنیم، و هر بار یکی یکی بگیریم و به آن بپردازیم. حتی باید برخی از قسمت های دامنه را کنار بگذاریم. یک دامنه حاوی اطلاعات بسیار زیادی است که همه آن را در مدل گنجانده است. و بسیاری از آن حتی لازم نیست در نظر گرفته شود. این خود یک چالش است. چه چیزی را باید نگه داشت و چه چیزی را دور انداخت؟ این بخشی از طراحی، فرآیند ایجاد نرم افزار است. نرم افزار بانکی مطمئناً آدرس مشتری را پیگیری می کند، اما نباید به رنگ چشم مشتری اهمیت دهد. این یک مورد واضح است، اما نمونه های دیگر ممکن است چندان واضح نباشند.یک مدل جزء ضروری طراحی نرم افزار است. ما به آن نیاز داریم تا بتوانیم با پیچیدگی مقابله کنیم. تمام فرآیند تفکر ما در مورد دامنه در این مدل ترکیب شده است. این خوب است، اما باید از ذهن ما خارج شود.اگر در آنجا بماند زیاد مفید نیست، درست است؟ما باید با این مدل با کارشناسان دامنه، با طراحان همکار و با توسعه دهندگان ارتباط برقرار کنیم. مدل ماهیت نرم افزار است، اما ما باید راه هایی برای بیان آن ایجاد کنیم تا با دیگران ارتباط برقرار کنیم. ما در این فرآیند تنها نیستیم، بنابراین باید دانش و اطلاعات را به اشتراک بگذاریم و باید آن را به خوبی، دقیق، کامل و بدون ابهام انجام دهیم. راه های مختلفی برای انجام آن وجود دارد. یکی گرافیکی است: نمودارها، موارد استفاده، نقاشی ها، تصاویر و غیره. دیگری نوشتن است. ما دیدگاه خود را در مورد دامنه یادداشت می کنیم. دیگری زبان است. ما می‌توانیم و باید زبانی برای برقراری ارتباط مسائل خاص در مورد دامنه ایجاد کنیم. همه اینها را بعداً شرح خواهیم داد، اما نکته اصلی این است که ما باید مدل را با هم ارتباط دهیم.وقتی یک مدل بیان شده داریم، می توانیم طراحی کد را شروع کنیم. این با طراحی نرم افزار متفاوت است. طراحی نرم افزار مانند ایجاد معماری یک خانه است، در مورد تصویر بزرگ است. از سوی دیگر، طراحی کد روی جزئیات کار می کند، مانند مکان یک نقاشی روی یک دیوار خاص. طراحی کد نیز بسیار مهم است، اما نه به اندازه طراحی نرم افزار. اشتباه طراحی کد معمولاً راحت تر اصلاح می شود، در حالی که تعمیر خطاهای طراحی نرم افزار بسیار هزینه بر است. این یک چیز است که یک نقاشی را بیشتر به سمت چپ منتقل کنید، و یک چیز کاملاً متفاوت است که یک طرف خانه را خراب کنید تا آن را متفاوت انجام دهید. با این حال محصول نهایی بدون طراحی کد خوب خوب نخواهد بود. در اینجا الگوهای طراحی کد مفید هستند و در صورت لزوم باید از آنها استفاده شود. تکنیک های کدنویسی خوب به ایجاد کد تمیز و قابل نگهداری کمک می کند.روش های مختلفی برای طراحی نرم افزار وجود دارد. یکی روش طراحی آبشار است. این روش شامل چند مرحله است. کارشناسان کسب و کار مجموعه ای از الزامات را ارائه می کنند که به تحلیلگران کسب و کار ابلاغ می شود. تحلیلگران بر اساس آن الزامات، مدلی ایجاد می‌کنند و نتایج را به توسعه‌دهندگان می‌فرستند تا براساس آنچه دریافت کرده‌اند، کدنویسی را آغاز کنند. این یک جریان یک طرفه دانش است. در حالی که این یک رویکرد سنتی در طراحی نرم‌افزار بوده و در طول سال‌ها با موفقیت خاصی مورد استفاده قرار گرفته است، معایب و محدودیت‌های خود را دارد. مشکل اصلی این است که هیچ بازخوردی از سوی تحلیلگران به کارشناسان کسب و کار یا توسعه دهندگان به تحلیلگران وجود ندارد.روش دیگر روش های چابک است، مانند برنامه نویسی شدید (XP). این روش‌شناسی حرکتی جمعی علیه رویکرد آبشار است که ناشی از دشواری‌های تلاش برای ارائه همه الزامات از قبل، به ویژه در پرتو تغییر الزامات است. ایجاد یک مدل کامل که تمام جنبه های یک دامنه را از قبل پوشش دهد، واقعاً سخت است. این نیاز به تفکر زیادی دارد و اغلب شما نمی توانید از همان ابتدا همه مسائل مربوط به آن را ببینید و همچنین نمی توانید برخی از عوارض جانبی منفی یا اشتباهات طراحی خود را پیش بینی کنید. مشکل دیگری که Agileبرای حل آن تلاش می کند، به اصطلاح «فلج تحلیلی» است که اعضای تیم آنقدر از تصمیم گیری در مورد طراحی می ترسند که اصلاً پیشرفتی نمی کنند. در حالی که طرفداران Agile اهمیت تصمیم گیری در طراحی را تشخیص می دهند، در مقابل طراحی اولیه مقاومت می کنند. در عوض آن‌ها از انعطاف‌پذیری زیادی در پیاده‌سازی استفاده می‌کنند، و از طریق توسعه مکرر با مشارکت مستمر ذینفعان کسب‌وکار و بازآفرینی‌های زیاد، تیم توسعه اطلاعات بیشتری در مورد دامنه مشتری کسب می‌کند و بهتر می‌تواند نرم‌افزاری تولید کند که نیازهای مشتریان را برآورده کند.روش های چابک مشکلات و محدودیت های خاص خود را دارند. آنها طرفدار سادگی هستند، اما هر کسی دیدگاه خود را نسبت به معنای آن دارد. همچنین، بازسازی مداوم توسط توسعه دهندگان بدون اصول طراحی جامد، کدی را تولید می کند که درک یا تغییر آن سخت است. و در حالی که رویکرد آبشار ممکن است منجر به مهندسی بیش از حد شود، ترس از مهندسی بیش از حد ممکن است به ترس دیگری منجر شود: ترس از انجام یک طراحی عمیق و کاملاً فکر شده.این نوشته اصول طراحی مبتنی بر دامنه را ارائه می‌کند، که در صورت اعمال می‌تواند توانایی هر فرآیند توسعه را برای مدل‌سازی و پیاده‌سازی مشکلات پیچیده در دامنه به روشی قابل نگهداری تا حد زیادی افزایش دهد. Domain Driven Designطراحی و توسعه را با هم ترکیب می کند و نشان می دهد که چگونه طراحی و توسعه می توانند برای ایجاد راه حل بهتر با یکدیگر همکاری کنند. طراحی خوب توسعه را تسریع می کند، در حالی که بازخوردهای حاصل از فرآیند توسعه طراحی را بهبود می بخشد.4 ساخت دانش دامنهبیایید مثالی از پروژه سیستم کنترل پرواز هواپیما و نحوه ایجاد دانش دامنه را در نظر بگیریم.هزاران هواپیما در یک لحظه معین در سراسر کره زمین در هوا هستند. آنها مسیرهای خود را به سمت مقصد خود طی می کنند و بسیار مهم است که از برخورد آنها در هوا اطمینان حاصل شود. ما سعی نمی کنیم در مورد کل سیستم کنترل ترافیک توضیح دهیم، بلکه در مورد یک زیر مجموعه کوچکتر که یک سیستم نظارت بر پرواز است، توضیح خواهیم داد. پروژه پیشنهادی یک سیستم نظارتی است که هر پرواز را در یک منطقه خاص ردیابی می کند، تعیین می کند که آیا پرواز مسیر فرضی خود را دنبال می کند یا خیر، و آیا احتمال برخورد وجود دارد یا خیر.از دیدگاه توسعه نرم افزار از کجا شروع کنیم؟ در قسمت قبل گفتیم که باید با درک حوزه شروع کنیم که در این مورد نظارت بر ترافیک هوایی است. کنترلرهای ترافیک هوایی متخصصین این حوزه هستند. اما کنترل کننده ها طراح سیستم یا متخصص نرم افزار نیستند. شما نمی توانید انتظار داشته باشید که آنها توضیح کاملی از دامنه مشکل خود به شما ارائه دهند.کنترلرهای ترافیک هوایی دانش گسترده ای در مورد دامنه خود دارند، اما برای اینکه بتوانید یک مدل بسازید، باید اطلاعات ضروری را استخراج کرده و آن را تعمیم دهید. وقتی شروع به صحبت با آنها می کنید، چیزهای زیادی در مورد پرواز و فرود هواپیماها، هواپیماهایی در هوا و خطر برخورد، هواپیماهایی که در انتظار فرود هستند و غیره خواهید شنید. باید از جایی شروع کنیمکنترل کننده و شما توافق می کنید که هر هواپیما دارای یک فرودگاه حرکت و یک مقصد است. بنابراین همانطور که در شکل زیر نشان داده شده است، یک هواپیما، یک حرکت و یک مقصد داریم.خوب، هواپیما از جایی بلند می شود و در جایی دیگر فرود می آید. اما در هوا چه اتفاقی می افتد؟ چه مسیر پروازی را طی می کند؟ در واقع ما بیشتر به آنچه در هوا متولد می شود علاقه مندیم. کنترل کننده می گوید که به هر هواپیما یک برنامه پرواز اختصاص داده شده است که قرار است کل سفر هوایی را توصیف کند. هنگام شنیدن یک برنامه پرواز، ممکن است در ذهن خود فکر کنید که این مربوط به مسیری است که هواپیما در هنگام پرواز طی کرده است. پس از بحث بیشتر، یک کلمه جالب می شنوید: مسیر. فورا توجه شما را به خود جلب می کند و دلیل خوبی هم دارد. مسیر حاوی مفهوم مهمی از سفر پرواز است. این کاری است که هواپیماها هنگام پرواز انجام می دهند، آنها یک مسیر را دنبال می کنند. بدیهی است که مبدا و مقصد هواپیما نیز نقطه شروع و پایان مسیر است. بنابراین، به جای مرتبط ساختن هواپیما با نقاط عزیمت و مقصد، طبیعی تر به نظر می رسد که آن را با یک مسیر مرتبط کنیم که به نوبه خود با مبدأ و مقصد مربوطه مرتبط است.با صحبت کردن با کنترل کننده در مورد مسیرهایی که هواپیماها دنبال می کنند، متوجه می شوید که در واقع مسیر از بخش های کوچکی تشکیل شده است که در کنار هم نوعی خط کج از مبدأ تا مقصد را تشکیل می دهند. خط قرار است از نقاط ثابت از پیش تعیین شده عبور کند. بنابراین، یک مسیر را می توان به عنوان یک سری اصلاحات متوالی در نظر گرفت. در این مرحله شما دیگر مبدأ و مقصد را به عنوان نقاط پایانی مسیر نمی بینید، بلکه فقط دو مورد دیگر از آن را رفع می کنید. این احتمالاً کاملاً با نحوه مشاهده کنترل کننده آنها متفاوت است، اما یک انتزاع ضروری است که بعداً کمک می کند. تغییرات حاصل بر اساس این اکتشافات عبارتند از:نمودار عنصر دیگری را نشان می دهد، این واقعیت که هر بدون تحرکی، یک نقطه در فضا است که مسیر دنبال می‌شود و به عنوان یک نقطه سه بعدی بیان می شود. اما وقتی با کنترلر صحبت می کنید، متوجه می شوید که او آن را اینطور نمی بیند. در واقع او مسیر را به عنوان پیش بینی پرواز هواپیما بر روی زمین می بیند. ثابت ها فقط نقاطی روی سطح زمین هستند که به طور منحصر به فرد با طول و عرض جغرافیایی تعیین می شوند. بنابراین نمودار صحیح این است:در واقع اینجا چه اتفاقی می افتد؟ شما و کارشناسان حوزه صحبت می کنید، شما در حال تبادل دانش هستید. شما شروع به سوال پرسیدن می کنید و آنها پاسخ می دهند. در حالی که آنها این کار را انجام می دهند، مفاهیم اساسی را از حوزه ترافیک هوایی بیرون می کشند. این مفاهیم ممکن است بدون شفافیت و بی نظم ظاهر شوند، اما با این وجود برای درک دامنه ضروری هستند. شما باید تا حد امکان در مورد دامنه از متخصصان بیاموزید. و با طرح سوالات مناسب و پردازش اطلاعات به روش صحیح، شما و کارشناسان شروع به ترسیم نمای دامنه، یک مدل دامنه خواهید کرد. این دیدگاه نه کامل است و نه صحیح، اما شروعی است که شما به آن نیاز دارید. سعی کنید مفاهیم اساسی دامنه را کشف کنید.این بخش مهمی از طراحی است. معمولاً بحث های طولانی بین معماران یا توسعه دهندگان نرم افزار و کارشناسان حوزه وجود دارد. متخصصان نرم افزار می خواهند دانش را از کارشناسان حوزه استخراج کنند و همچنین باید آن را به شکل مفیدی تبدیل کنند. در برخی موارد، آنها ممکن است بخواهند یک نمونه اولیه ایجاد کنند تا ببینند تا کنون چگونه کار می کند. در حین انجام این کار، ممکن است برخی مشکلات را در مدل یا رویکرد خود پیدا کنند و ممکن است بخواهند مدل را تغییر دهند. ارتباط تنها یک راه نیست، از کارشناسان حوزه تا معمار نرم افزار و بیشتر به توسعه دهندگان. همچنین بازخوردی وجود دارد که به ایجاد یک مدل بهتر و درک واضح تر و صحیح تر از دامنه کمک می کند. کارشناسان دامنه به خوبی حوزه تخصصی خود را می شناسند، اما دانش خود را به روشی خاص سازماندهی و استفاده می کنند، که همیشه بهترین راه برای پیاده سازی در یک سیستم نرم افزاری نیست. ذهن تحلیلی طراح نرم افزار به کشف برخی از مفاهیم کلیدی نرم افزار کمک می کند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»