خلاصه مروری از فصل های 15 تا 29 و 30 تا 34 کتاب معماری تمیز نوشته رابرت سی مارتین

معماری به طراحی یک سیستم اشاره می کند ، با هدف ایجاد ساختاری که الزامات خاصی را برآورده می کند در حالی که عواملی مانند عملکرد ، حفظ قابلیت ، مقیاس پذیری و قابلیت استفاده را نیز در نظر می گیرد . در مهندسی نرم افزار، معماری به طراحی سیستم نرم افزار از جمله اجزای آن، رابط ها و روابط بین آنها اشاره دارد . یک طراحی خوب در معماری نرم افزار می تواند تفاوت قابل توجهی در کیفیت ، قابلیت نگهداری و مقیاس پذیری سیستم نرم افزار ایجاد کند . معماری به طراحی یک سیستم از جمله ساختار، رفتار و روابط بین اجزای آن اشاره دارد . در توسعه نرم افزار معماری ، طراحی سطح بالایی از نرم افزار را توصیف می کند از جمله چگونگی سازماندهی آن، اجزای اصلی که سیستم را تشکیل می دهند و اینکه چگونه این اجزای با یکدیگر ارتباط برقرار می کنند . هدف از معماری نرم افزار ایجاد یک سیستم است که به آسانی قابلیت حفظ، مقیاس پذیری و سازگاری با تغییر الزامات را دارا باشد . کتاب معماری تمیز راهنمای ساخت سیستم های نرم افزاری ای است که برای حفظ ، گسترش و تغییر آسان هستند . فصل استقلال ، درباره اهمیت ایجاد اجزای مستقل در یک سیستم نرم افزاری بحث می کند . به گفته مارتین، اجزای مستقل کسانی هستند که می توانند بدون تاثیر بر رفتار اجزای دیگر تغییر کنند . او استدلال می کند که ایجاد اجزای مستقل برای ساخت سیستم های نرم افزاری که انعطاف پذیر و آسان برای حفظ هستند ضروری است. در فصل استقلال، مارتین چندین استراتژی برای ایجاد اجزای مستقل، از جمله استفاده از رابط ها، انتزاع ها و جدایی نگرانی ها را مورد بحث قرار می دهد. او همچنین در مورد اهمیت اجتناب از اتصال سخت بین اجزا بحث می کند و بر نیاز به ایجاد سیستم های متصل به هم تاکید می کند.در مبحث خط مرزی بر اهمیت ترسیم یک خط روشن بین دو سیستم مختلف در تلاش برای حفظ یکپارچگی هر سیستم تمرکز داریم . این قسمت با معرفی مفهوم خط مرزی آغاز می شود که یک خط نظری است که دو سیستم مختلف را جدا می کند . خط مرزی به عنوان یک مرز عمل می کند که مانع از دخالت یک سیستم در سیستم دیگر می شود . این قسمت توضیح می دهد که وقتی سیستم ها به وضوح از هم جدا نمی شوند ، می تواند منجر به تعدادی از مسائل ، از جمله افزایش پیچیدگی ، کاهش قابلیت نگهداری و کاهش عملکرد شود . با ترسیم خط مرزی شفاف بین دو سیستم ، مدیریت و نگهداری هر سیستم به طور مستقل آسان تر می شود . این قسمت همچنین در مورد اهمیت استفاده از رابط های مناسب برای تسهیل ارتباط بین دو سیستم بحث می کند . استفاده از رابط های روشن و به خوبی تعریف شده می تواند اطمینان حاصل کند که هر سیستم به طور مستقل عمل می کند و با دیگری تداخل ندارد . به طور کلی، معماری تمیز اهمیت طراحی خط مرزی روشن بین دو سیستم مختلف را برای حفظ یکپارچگی هر سیستم برجسته می کند . با استفاده از رابط های مناسب و مرزهای روشن ، مدیریت و حفظ هر سیستم به طور مستقل آسان تر می شود. در ادامه به اهمیت تعریف مرزهای روشن بین اجزای مختلف یک سیستم نرم افزار پرداخته میشود . نویسنده استدلال می کند که بدون مرزهای روشن ، سیستم های نرم افزاری برای حفظ ، گسترش و تغییر در طول زمان دشوار می شوند . و از مفهوم "Dependency Inversion" به عنوان راهی برای ایجاد مرزهای روشن بین اجزا بحث می کند . عدم وابستگی شامل تجزیه و تحلیل وابستگی بین دو جزء است . به طوری که اجزایی که به احتمال زیاد تغییر می کنند به اجزایی که کمتر احتمال دارد تغییر کند ، وابسته نیستند . این به کاهش تاثیر تغییرات در یک جزء بر اجزای دیگر در سیستم کمک می کند .درگام بعدی بر سیاست و سطح طراحی نرم افزار تمرکز داریم . کتاب بر اهمیت در نظر گرفتن جنبه های سیاسی طراحی نرم افزار و چگونگی تاثیر آن بر معماری کلی سیستم تأکید می کند . استدلال میشود که جنبه های سیاسی طراحی نرم افزار به اندازه جنبه های فنی مهم است و نباید نادیده گرفته شود . همچنین در مورد سطوح مختلف طراحی نرم افزار، از جمله لایه نرم افزار، لایه زیرساخت و لایه پایه بحث میشود . نویسنده استدلال می کند که هر لایه باید با مجموعه ای از اصول و مرزهای خود ، بر اساس نیازهای خاص سیستم طراحی شود . مارتین بر اهمیت نگه داشتن هر لایه جداگانه و مستقل تاکید می کند تا اطمینان حاصل شود که تغییرات در یک لایه بر لایه های دیگر تأثیر نمی گذارد . در طول فصل ، نمونه هایی از چگونگی اعمال این اصول به سناریوهای طراحی نرم افزار در دنیای واقعی ارائه شده است . بحث اصلی در مورد اهمیت استفاده از ابزار و فن آوری های مناسب برای هر لایه و چگونگی اطمینان از اینکه لایه های مختلف به صورت یکپارچه کار می کنند ، است . به طور کلی ، این بخش از کتاب معماری تمیز نقش یک راهنمای جامع را برای جنبه های سیاسی و سطح طراحی نرم افزار فراهم می کند.در بخش قانون کسب و کار ، ما در مورد چگونگی اطمینان از اینکه نرم افزار مطابق با الزامات دامنه کسب و کار است ، بحث می کنیم . دامنه کسب و کار مجموعه ای از قوانین و محدودیت هایی است که رفتار نرم افزار را اداره می کند . تاکید شده است که دامنه کسب و کار از دامنه نرم افزار جدا است . دامنه نرم افزار مجموعه ای از قوانین و محدودیت هایی است که رفتار خود نرم افزار را اداره می کند . ضروری است که این دو دامنه را جداگانه نگه داریم تا اطمینان حاصل شود که نرم افزار مطابق با الزامات دامنه کسب و کار است . برای دستیابی به این جدایی ، استفاده از زمینه های محدود را پیشنهاد میشود . یک زمینه محدود مجموعه ای از کلاس ها است که یک واژگان مشترک را به اشتراک می گذارند و مسئول جنبه خاصی از دامنه کسب و کار هستند . هر زمینه محدود باید مخزن و نقشه برداری خود را به دیگر زمینه های محدود داشته باشد . نویسنده همچنین درباره اهمیت مدل سازی داده های مناسب بحث می کند . او پیشنهاد می کند که مدل داده ها باید بر اساس دامنه کسب و کار و نه بر روی دامنه نرم افزار باشد . مدل داده ها باید نهادهای واقعی و روابط موجود در حوزه کسب و کار را نشان دهد . در نهایت ، خوهیم دید که این نرم افزار باید برای تسهیل تست طراحی شود . تست برای اطمینان از اینکه نرم افزار مطابق با الزامات دامنه کسب و کار است ضروری است. درواقع نکته مورد توجه ما اهمیت نگه داشتن نرم افزار ، جدا از دامنه کسب و کار وکسب اطمینان از این است که نرم افزار مطابق با الزامات دامنه کسب و کار است . زمینه های پراکنده ، مدل سازی داده های مناسب و قابلیت آزمایش ، همه ملاحظات مهم در هنگام طراحی نرم افزار است که نیازهای دامنه کسب و کار را برآورده می کند.در ادامه در مورد اهمیت معماری تمیز در توسعه نرم افزار بحث میشود . کتاب استدلال می کند که معماری تمیز در ایجاد سیستم های نرم افزاری قابل نگهداری ، مقیاس پذیر و غیر قابل بازیافت ضروری است . این فصل با معرفی مختصر به معماری نرم افزار آغاز می شود و آن را به عنوان فرایند طراحی یک سیستم نرم افزار برای پاسخگویی به الزامات کاربر تعریف می کند . کتاب بر اهمیت معماری خوب در توسعه نرم افزار تاکید می کند و بیان می کند که برای موفقیت هر پروژه نرم افزاری مهم است . نویسنده سپس مفهوم فرسایش ساختاری را معرفی می کند که زمانی اتفاق می افتد که یک سیستم بیش از حد پیچیده و دشوار شود . این می تواند منجر به کاهش بهره وری و افزایش در مقدار زمان و منابع مورد نیاز برای رفع اشکالات و پیاده سازی ویژگی های جدید شود . برای جلوگیری از فرسایش معماری ، کتاب اصول معماری تمیز را ارائه می دهد . این اصول شامل جدا کردن سیستم به لایه های متمایز، استفاده از رابط ها برای تعریف روابط بین لایه ها و اجرای اصل عدم وابستگی برای ترویج اتصال شل بین اجزا است . این فصل همچنین در مورد اهمیت تست و کیفیت کد در حفظ یک معماری تمیز بحث می کند . نویسنده استدلال می کند که تست باید بخشی جدایی ناپذیر از فرآیند توسعه باشد و باید هر دو به صورت دستی و از طریق ابزارهای خودکار انجام شود. به طور کلی، این فصل بر اهمیت معماری تمیز در توسعه نرم افزار تأکید می کند و مشاوره عملی در مورد چگونگی دستیابی به آن را فراهم می کند. با پیروی از اصول ذکر شده در فصل، توسعه دهندگان می توانند سیستم های نرم افزاری قابل نگهداری، مقیاس پذیر و غیر قابل پیش بینی را ایجاد کنند که نیازهای کاربران خود را برآورده می کنند.در ادامه بحث در مورد اهمیت ارائه و فروتنی در توسعه نرم افزار را داریم . رابرت مارتین بر نیاز توسعه دهندگان برای برقراری ارتباط موثر ایده های خود و انجام این کار با تواضع تاکید می کند . پس از بحث در مورد اهمیت ارتباطات و فروتنی، کتاب در مورد چگونگی استفاده از این ویژگی ها در توسعه نرم افزار صحبت می کند . بیان میشود که توسعه دهندگان باید تلاش کنند تا نرم افزاری ایجاد کنند که درک و نگهداری آن آسان است و این نیاز به تمرکز بر معماری تمیز دارد . کتاب در مورد چند اصل کلیدی معماری تمیز، از جمله جدایی از نگرانی ها ، لایه برداری و انتزاع بحث می کند . توضیح این است که این اصول می تواند به ایجاد نرم افزاری که ماژولارتر، قابلیت آزمایش آسانتر و کمتر مستعد خطا است کمک کند . سپس به بحث در مورد نقش ارائه دهنده در توسعه نرم افزار را داریم . کتاب توضیح می دهد که ارائه دهنده مسئول گرفتن داده های پیچیده و ارائه آن به روشی است که برای کاربران آسان است و بر اهمیت موجود بودن مستقل از منبع داده تاکید می کند . به طوری که می تواند به راحتی جایگزین یا اصلاح شود بدون اینکه بر سایر بخش های سیستم تأثیر بگذارد . به طور کلی، اهمیت ارتباطات ، تواضع و معماری تمیز در توسعه نرم افزار مورد تأکید است . این یک چارچوب برای توسعه دهندگان فراهم می کند تا نرم افزار را ایجاد کنند که به این شکل درک، حفظ و آزمایش آن آسان تر است، در حالی که همچنین بر اهمیت ارتباطات موثر و همکاری تاکید می کند.یک مرز خطی است که دو چیز را جدا می کند و در معماری نرم افزار به مرز بین اجزا اشاره می کند. ایده این است که هر جزء باید یک مرز به خوبی تعریف شده داشته باشد ، اما آنچه که یک مرز را تشکیل می دهد می تواند سخت تر باشد . در چارچوب مرزهای جزئی، مارتین استدلال می کند که گاهی اوقات مفید است که یک جزء با یک مرز جزئی داشته باشیم. این بدان معنی است که برخی از تعاملات با جزء خارج از مرز آن هستند، در حالی که دیگر بخش ها در داخل هستند . یکی از مزایای مرزهای جزئی این است که می تواند معماری را انعطاف پذیرتر کند . با داشتن اجزای دارای مرزهای جزئی، می توانیم بدون نیاز به تغییر کل معماری ، تغییراتی در سیستم ایجاد کنیم . یکی دیگر از مزایای آن این است که می تواند طراحی را مدولار تر کند ، که می تواند درک و نگهداری آن را آسان تر کند. با این حال، مشکلات بالقوه ای برای استفاده از مرزهای جزئی وجود دارد. یکی این است که می تواند طراحی را پیچیده تر کند ، زیرا نیاز به تفکر بیشتر برای تعیین اینکه مرزها باید کجا باشند دارد. یکی دیگر این است که می تواند دلیل آن را در مورد سیستم سخت تر کند، زیرا تعیین دقیق اینکه کدام تعاملات در داخل یا خارج از مرز قرار دارند ، دشوار است . به طور خلاصه، مفهوم مرزهای جزئی یک ابزار مفید در معماری نرم افزار است، اما باید به دقت و با فکر مورد استفاده قرار گیرد . با توجه به مزایای و معایب ، ما می توانیم یک معماری انعطاف پذیر تر و مدولار تر ایجاد کنیم که درک و نگهداری آن آسان تر است. هدف ما پی بردن به اهمیت معماری تمیز در جلوگیری از پیچیدگی غیر ضروری و کاهش خطر بدهی است . همچنین بر نیاز به مرزهای روشن بین اجزا و لایه ها در یک برنامه برای ترویج مدولار بودن و انعطاف پذیری تأکید می کنیم . کتاباهمیت توجه به تاثیر تغییرات در سیستم و تصمیم گیری آگاهانه در مورد جایی که خطوط بین اجزای مختلف را ترسیم می کند را برجسته می کند . به طور کلی، در اینجا بر اهمیت طراحی یک سیستم تاکید میشود که حفظ و مقیاس پذیری آن ،آسان است در حالی که به حداقل رساندن خطر بدهی و کاهش احتمال بروز مشکلات غیرمنتظره در آینده است. ما در ادامه مباحث با مفهوم The Main Speed مواجه خواهیم بود که به این ایده اشاره می کند که سرعت اصلی یک سیستم باید با آهسته ترین جزء در سیستم مشخص شود. به عبارت دیگر، عملکرد کلی سیستم نباید توسط سریع ترین جزء تعیین شود ، بلکه با کندترین بخش مشخص می شود. این یک مفهوم مهم برای نگه داشتن در هنگام طراحی و پیاده سازی سیستم ها است، زیرا می تواند اطمینان حاصل کند که سیستم کارآمد و پاسخگو است حتی زمانی که با اجزای آهسته تر سروکار دارد. در بحث سرویس ها توضیحات کتاب حول مفهوم خدمات بالا و کوچک می چرخد . نویسنده بر اهمیت جدا کردن نگرانی های یک برنامه به اجزای کوچکتر و قابل کنترل تر تأکید می کند . در این موضوعات با بحث در مورد مزایای استفاده از خدمات کوچک مانند تست آسان تر، تعمیر و نگهداری و مقیاس پذیری آغاز می شود . توضیح داده میشود که خدمات کوچک آسان تر برای درک و اصلاح هستند و می توانند به طور مستقل و بدون تاثیر بر بقیه سیستم، مقیاس یابند. نویسنده همچنین اهمیت استفاده از خدمات سطح بالا را برجسته می کند که یک انتزاع سطح بالایی از عملکرد سیستم را ارائه می دهد . این خدمات باید به لایه هایی که جدایی روشنی از نگرانی ها و مسئولیت ها را فراهم می کنند ، سازماندهی شود . سپس در مورد معاملات بین اتصال شل و اتصال سخت و چگونگی دستیابی به هر دو در یک سیستم واحد بحث می کند . نویسنده نشان می دهد که اتصال شل را می توان از طریق استفاده از رابط ها و انتزاع ها به دست آورد، در حالی که اتصال محکم را می توان از طریق حالت مشترک و انتقال پیام به دست آورد . این موضوعات با تاکید بر اهمیت استفاده از ابزار مناسب برای کار و اجتناب از پیچیدگی غیر ضروری به پایان می رسند. به طور خلاصه، این مبحث بر اهمیت استفاده از خدمات کوچک و خدمات سطح بالا سازماندهی شده به لایه ها برای دستیابی به اتصال شل و اتصال محکم تاکید می کند و سادگی و وضوح برای ایجاد سیستم های قابل نگهداری و مقیاس پذیر ضروری است.در پایان رابرت سی مارتین در مورد مفهوم مرزهای آزمون و چگونگی استفاده از آنها برای بهبود کیفیت سیستم های نرم افزار بحث می کند . مرزهای تست به مرزها یا رابط بین اجزای یک سیستم نرم افزاری که برای تست استفاده می شود اشاره می کنند . یک جزء با مرزهای آزمون روشن ، آسان تر برای تست و نگهداری خواهد بود . زیرا جداسازی و دستکاری اجزای فردی برای اهداف تست آسان تر خواهد بود . کتاب استدلال می کند که مرزهای آزمون برای دستیابی به سطح بالایی از کیفیت کد و قابلیت نگهداری ضروری است و نشان می دهد که توسعه دهندگان همیشه باید تلاش کنند تا اجزایی را با مرزهای تست تعریف شده ایجاد کنند و باید سیستم های خود را با چشم به سمت انجام تست به عنوان کارآمد طراحی کنند . نویسنده همچنین در مورد اهمیت ایجاد سلسله مراتبی از مرزهای آزمون، با اجزای کوچکتر و متمرکز تر با محدودیت های تست کمتر و اجزای بزرگتر و پیچیده تر که دارای مرزهای آزمایش بیشتری هستند، بحث می کند . با ایجاد سلسله مراتبی از مرزهای آزمون، توسعه دهندگان می توانند سیستم هایی ایجاد کنند که هم قابل آزمایش و هم مقیاس پذیر هستند. به طور کلی، اهمیت مرزهای آزمون در طراحی سیستم نرم افزار و چگونگی استفاده از آنها برای بهبود کیفیت کلی و حفظ سیستم های نرم افزار مورد تاکید است .در فصل 30 ام این کتاب به بررسی اهمیت و نحوه یکپارچه‌سازی بانک اطلاعاتی در یک سیستم نرم‌افزاری پرداخته شده است. در این فصل، نویسنده به اهمیت طراحی دقیق بانک اطلاعاتی و اینکه چگونه باید آن را به عنوان یک جزء از ساختار کل سیستم معرفی کنیم، پرداخته و بر اهمیت طراحی درست و بهینه بانک اطلاعاتی به منظور اجتناب از اشکالات و ارتقاء کارایی سیستم اشاره شده است. رابرت سی مارتین در این فصل به مباحثی همچون نحوه افزایش یکپارچگی بین بانک اطلاعاتی و لایه‌های دیگر سیستم، استفاده از الگوهای طراحی مناسب برای بانک اطلاعاتی، و نکاتی که باید در طراحی این قسمت از سیستم مدنظر قرار گیرد، می‌پردازد. همچنین اهمیت انطباق بانک اطلاعاتی با نیازهای کسب و کار و استفاده از استانداردهای مناسب نیز تاکید شده است.علاوه بر این، به انتخاب مناسب نوع دیتابیس، افزایش قابلیت اطمینان (reliability) و مقیاس‌پذیری (scalability) بانک اطلاعاتی، استفاده از الگوهای طراحی شیء ، رابطه (Object-Relational Design Patterns)، و نحوه یکپارچه‌سازی بانک اطلاعاتی با لایه‌های دیگر سیستم اشاره شده است . به طور کلی، در این فصل مؤلف به خواننده نشان می‌دهد که چگونه معماری تمیز در طراحی بانک اطلاعاتی می‌تواند به بهبود اداء و گسترش پروژه‌های نرم‌افزاری کمک کند.در ادامه رابرت سی مارتین به مفهوم و اهمیت معماری سیستم‌ها و تأثیر آن بر توسعه و نگهداری نرم‌افزارها پرداخته و بیان میشود که وب به عنوان یک جزء از کل سیستم، نقش بسیار حیاتی دارد و باید به عنوان یک رکن مهم در معماری نرم‌افزار در نظر گرفته شود.مارتین تأکید دارد که معماری تمیز به معنای جداکردن مسائل و بخش‌های مختلف سیستم باعث ایجاد انعطاف‌پذیری، قابلیت تغییر و نگهداری ساده‌تر می‌شود. او بر اهمیت اصول SOLID و تکنیک‌های معماری سطح بالا برای ایجاد ساختارهای کدی قابل فهم و توسعه‌پذیر تأکید می‌کند.همچنین، مارتین به اهمیت مستندسازی صحیح معماری و استفاده از الگوهای معماری معروف مانند MVC (مدل-ویو-کنترلر) و Dependency Injection (تزریق وابستگی) می‌پردازد. او توصیه می‌کند که توسعه‌دهندگان به توازن بین انعطاف‌پذیری و پایداری در معماری توجه داشته باشند و از اصول Clean Code (کد تمیز) در تمام لایه‌های سیستم استفاده کنند . این بخش به خوانندگان کمک می‌کند تا درک عمیق‌تری از اهمیت معماری تمیز در توسعه نرم‌افزارها، به ویژه در فضای وب، پیدا کنند و اصول مهمی را برای ایجاد سیستم‌های با کیفیت و سازگار با تغییرات معرفی می‌کند. در ادامه به اهمیت فریم ورک ها در معماری مدرن پرداخته میشود. و توضیح داده میشود که فریم ورک ها اجزای اصلی معماری هستند که به طور گسترده در ساخت و توسعه نرم افزارها استفاده می‌شوند. نویسنده به بررسی نحوه استفاده از فریم ورک ها در طراحی ساختارهای پایدار و قابل توسعه معماری مدرن پرداخته و روش‌های بهینه سازی استفاده از آن‌ها را شرح می‌دهد. این فصل به خواننده کمک می‌کند تا با دقت بیشتر به طراحی و پیاده سازی فرآیندهای معمارانه در پروژه‌های خود بپردازد. در این فصل، نویسنده به توضیح دقیق و جامع در مورد نقش و اهمیت فریم ورک ها در طراحی و توسعه سیستم‌های نرم‌افزاری می‌پردازد. فریم ورک ها به عنوان چارچوب‌های کلی برای ساختاردهی و توسعه سامانه‌های نرم‌افزاری استفاده می‌شوند. آن‌ها شامل قطعات کد، الگوهای طراحی، استانداردها و قوانین استفاده شده در چیدمان و اجزاء سامانه هستند. فرآیندهای تکنولوژيكي كه بيشتر اين روزها با استفاده از فضای ديجيتال صورت می گيرد، باعث شده است كه نقش فرآیندهایی نظير Project Management ، كنترل كيفي (Quality Control)، طبقات (Layers)، الگو ها (Patterns)، چارچوب ها (Frameworks) و ... حائز اهمیت شود. بخش‌های مختلف فصل 32 به بحث در مورد اجزاء مختلف فریم ورک ها پرداخته شده است. این بخش‌ها شامل تعاریف دقیق و جامع در مورد قطعات کد، الگوهای طراحی، استانداردها و قوانین استفاده شده در فرآیندهای تکنولوژيكي هستند.در ادامه فصل بعدی مجموعه این قوانین و افکار در مورد معماری را در یک مطالعه موردی کوتاه و ساده کنار هم و مورد مطالعه قرار میدهیم که هم فرآیندی را که یک معمار خوب استفاده می کند و هم تصمیماتی را که چنین معمار می گیرد، به تصویر می کشد.مطالعه موردی ما ،نرم‌افزاری برای وب‌سایتی است که فیلم می‌فروشد. ما یک سری ویدیو داریم که می خواهیم بفروشیم. ما آنها را در وب به افراد و مشاغل می فروشیم. افراد می‌توانند یک قیمت برای مشاهده ویدیوها بپردازند و قیمت دیگری برای دانلود آن ویدیوها و مالکیت دائمی آنها. افراد معمولاً هم به عنوان بیننده و هم به عنوان خریدار عمل می کنند. در مقابل، کسب‌وکارها اغلب افرادی دارند که ویدیوهایی را می‌خرند که دیگران تماشا خواهند کرد.تولیدکنندگان ویدئو باید فایل‌های ویدئویی، توضیحات نوشته شده و فایل‌های جانبی خود را با آزمون‌ها، مشکلات، راه‌حل‌ها، کد منبع و سایر مطالب ارائه کنند.مدیران باید توانایی این را داشته باشند که ویدیوها را به مجموعه اضافه و حذف کنند، و قیمت محصولات ویدیویی مختلف را تعیین کنند.اولین قدم ما در تعیین معماری اولیه سیستم، شناسایی بازیگران و مواردکاربری است.مطابق شکل زیر :شکل 1چهار بازیگر اصلی مشخص هستند. بر اساس اصل مسئولیت واحد، این چهار بازیگر، چهار منبع اصلی تغییر برای سیستم خواهند بود. هر بار که برخی از ویژگی های جدید اضافه می شود، یا برخی از ویژگی های موجود تغییر می کنند، این مرحله برای خدمت به یکی از این بازیگران به اجرا گذاشته می شود. بنابراین ما می خواهیم سیستم را به گونه ای تقسیم بندی کنیم که تغییر در یک بازیگر بر هیچ یک از بازیگران دیگر تأثیری نگذارد.یوزکیس های نشان داده شده در شکل 1 ، یک لیست کامل نیستند.که برای خلاصه سازی این کار انجام شده است . به عنوان مثال، ورودی و خروجی USE CASE ها را نمیتوانیم ببینیم . اکنون که ما ACTOR ها و USE CASE را میشناسیم ، میتوانیم یک معماری بر اساس کامپوننت های اولیه ایجاد کنیم . مطابق شکل 2 خطوط دوتایی در نقشه، مرزهای معماری را نشان می دهد. می توانیم پارتیشن بندی معمولی نماها، ارائه دهندگان، تعامل کنندگان و کنترلرها را مشاهده کنیم. هر کامپوننت در شکل 2 یک فایل jar. یا فایل dll . بالقوه را نشان می دهد. هر یک از این مؤلفه‌ها شامل نماها، ارائه‌کنندگان، تعامل‌کنندگان و کنترل‌کننده‌هایی است که به آن اختصاص داده شده‌اند.حال به کامپوننت های خاص برای نمایش کاتالوگ و ارائه کننده کاتالوگ توجه کنید. این روش نحوه برخورد با USECASE انتراعی VIEW CATALOG است .شکل 2در نتیجه نمودار معماری در شکل 2 ، شامل دو بعد جداسازی است. اولی جدایی بازیگران بر اساس اصل مسئولیت واحد است. و دومین بعد ، قانون وابستگی است. هدف هر دو جداسازی کامپوننت هایی است که به دلایل مختلف و با نسبت های متفاوت تغییر می کنند. دلایل مختلف به بازیگران مربوط است و نسبت های مختلف به سطوح مختلف خط مشی مربوط است . پس از ساختن کد به این روش میتوانیم نحوه توسعه سیستم را با یکدیگر هماهنگ و مطابقت دهیم و در هنگام تغییر شرایط ، گروه را به راحتی تغییر دهیم . ما میتوانیم کامپوننت ها را به هر روشی که معقول باشد ، در فایل های قابل تحویل و توسعه قرار دهیم و در هنگام تغییر شرایط ، گروه را به راحتی تغییر دهیم .