Clean Architecture

לאחרונה יצא לי להרצות בשתי פורומים שונים על ארכיטקטורה שהתוועדתי אליה באחת העבודות הקודמות שלי.

התנסיתי בה באופן אישי, במשך כמה חודשים טובים, בארגון שקיבל החלטה להעביר service מ .Net Famework ל .NetCore 3.x, וה CTO בחברה לקח כמה החלטות ארכיטקטוניות ובכללם ללכת על הארכיטקטורה הזאת, פלוס עוד כמה מתודולוגיות פיתוח ו design patterns שאפרט בסוף.

תוכלו למצוא בסוף הפוסט, את המצגת וגם וידאו הקלטה של ההרצאה

היא הוצגה ע"י רוברט ססיל מרטין, AKA "דוד בוב", שמוכר ביותר בפיתוח עקרונות רבים לתכנון תוכנה ובהיותו מייסד המניפסט האג'ילי. בנוסף חמישה מעקרונותיו של מרטין נודעו יחד כעקרונות ה  SOLID

הארכיטקטורה מכסה הרבה קונספטים בעייתיים ולכן היא קצת קשה להכלה,
היא לוקחת הרבה מאוד בעיות בתכנות ומנסה לפתור אותם

באופן אישי – מה שהכי אהבתי בארכיטקטורה, הקלות שבה אפליקציה עוברת frameworks.
אם למשל ניקח כדוגמא שירות דוטנט, נוכל להמיר אותו בקלות לאפליקציית אנגולר, ולקחת ממנו את החלקים הרלוונטיים כמו שכבת המודלים הנקייה, או business rules שמעוניינים בהם. פשוט נדרש לעשות התאמות נדרשות למעבר בין שפות C# ל TS

אין שום external resource dependency בשכבות הנ"ל, הקוד הוא pure לגמרי, ומשקף נטו את ה essence של האפליקציה.

הקונספט המרכזי של הארכיטקטורה של בוב, הוא הקו של קוד נקי pure code ככל שניתן, והוא שיקול שאמור להיכלל בקבלת כל החלטה על ארכיטקטורה שהיא.

בעצם, בעידן שבו יש סחרור טכנולוגי, זה הופך את זה לשיקול מרכזי.

בעיניי, בקונספט הזה, זה לא חייב להיות ארכיטקטורה שחייבים להיצמד, אלא החלטה שהארגון מקבל ומנחיל לעובדים כמו ה solid principals .
אני הייתי מוסיפה פשוט ל SOLID את סיומת PC כדי להזכיר את עקרון ה pure code  בכל כתיבה בכל קובץ שהוא במערכת.

למה בכלל ארכיטקטורה?

ארכיטקטורות מאפשרות ניתוק יחידות שונות של הקוד שלך בצורה מסודרת ומנוהלת. באופן זה קל יותר להבין, לשנות ולבדוק את הקוד.
בארגון גדול, שבו צוותים שונים נוגעים באותו קוד, ומתכנתים מתחלפים בקצב, ארכיטקטורה עוזרת להחיל קונבנציות ארגוניות מקובלות אשר מקלות על נראות, קריאות ותחזוקת הקוד לטווח הרחוק.

Compare to Layers Architecture

אקח כהשוואה את ארכיטקטורת השכבות, בתקווה שבעצם היותה שכיחה, תעזור להבנה.
אם ניקח את מודל השכבות, ונבחן אותו ברמת התלות של השכבות ב resource חיצוני כמו ה framework שנבחר עבור ממשק השתמש – GUI או ה DB לאחסון הנתונים, נמצא שבעצם רק שכבת ה BL נקייה לכאורה מטכנולוגיות ו.או tools וderivers שהתוכנה משתמשת בהם.

מה גם שבשכבת הלוגיקה העסקית יש הרבה תלויות חיצוניות, אם זה בהשפעת ה DB ואו הGUI, וגם שימוש ב external libraries, system files accessing, external web services, וכל שאר הדברים שמשמשים אותנו בפיתוח האפליקציה ונמצאים על הלוגיקה העסקית שלנו, או אפילו על המודלים הפשוטים שמשמשים אותנו באפליקציה.
לדוגמא Annotations על properties של class או inheritance של class בשביל לאפשר וואלידציות במודל, המרות לפורמטים שונים, וכלים שימושים שונים שחוסכים לנו הרבה פיתוח, ומנוהלים בחבילות חיצוניות.
כלומר זה מייצר לנו המון קוד שאינו בהכרח קשור ל essence של האפליקציה, ומרובה תלויות בדברים שאינם בשליטתנו, אשר מהותם היא להשתנות ללא הרף. הרבה יותר מאשר השינויים בלוגיקה שמתארת את המהות של האפליקציה שלנו.

אם ננסה לעבור לטכנולוגיה או פריימוורק חדשים, זה יכול להיות קשה יותר, השינוי כמסתבר יהיה רוחבי כמעט באופן מלא, וכל השכבות כולם יצטרכו לעבור rewrite והתאמות. גם אם מדובר במעבר באותה שפה C#, לדוגמא, במעבר בין dotnet framework ל – dotnet core.

בעבודה קודמת, כשהארגון החליט לעבור מSOA ודוטנט פריימוורק לדוטנט core עם Micro Services, קיבלתי אחריות להתחיל עם שירות קטן יחסית ולבצע את המעבר. לכאורה הציפייה הייתה שהעברת שירות אחד, תקח מעט זמן. כי זה C# ל C#.

מה שהתגלה הפתיע אותי.

אפילו class אחד לא יכולתי להעביר כמו שהוא, model הכי פשוט.
על השדות היו attributes של JSON ושל MVC וואלידציות מכל מיני סוגים, והורשות שונות בתלויות חיצוניות מחבילות שכבר לא נתמכו ב .Net Core.
השכתוב של האפליקציה היה מלא, ולא הספיק מתכנתת אחד, צוות יצטרך לעבוד על זה כדי להביא מוצר מוגמר.

Similar Architectures To The Clean Architecture

יש כמה ארכיטקטורות דומות כמו זאת:

Hexagonal Architecture (a.k.a. Ports and Adapters)

Onion Architecture

Screaming Architecture from a blog of mine

למרות שארכיטקטורות אלה שונות במקצת בפרטיהן, הן דומות מאוד. 
לכולם אותה מטרה שהיא Separation of Concerns. וכולם משיגים הפרדה זו על ידי חלוקת התוכנה לשכבות.
לכל אחד מהם יש לפחות שכבה אחת ל – business rules, ועוד אחרת עבור ה – interfaces.

הדבר שהכי מאחד אותם הוא, שכולם מאפשרות לך לייצר ארכיטקטורה שהיא  free of cycles – no circular dependency,  שעדיין מצליחה לתקשר בין השכבות בצורה אפקטיבית. מה שמוודא שכאשר יש שינוי בקוד, הוא יתקל במהרה firewall , בקצה של השכבה הנוכחית שבה מעניין השנוי, מאשר להתפשט לעבר כמה חלקי קוד, breaking component after component..

The Clean Architecture

Architecture Goals

1. Independence from Framework
   הארכיטקטורה אינה תלויה בקיומה של ספרייה כלשהי. זה מאפשר לך להשתמש באיזה framework שתבחרת בצורת שימוש as tool, כלומר לא תצטרך לדחוס את המערכת שלך ל  limited constraints של כל ספרייה שהיא.
2. Testable
   ניתן לבדוק את הכללים העסקיים business rules ללא ממשק המשתמש, מסד הנתונים, שרת האינטרנט או כל אלמנט חיצוני אחר.
3. Independent of UI
    ממשק המשתמש יכול להשתנות בקלות, מבלי לשנות את שאר המערכת. 
   למשל Web UI יכול להיות מוחלף ב Console UI, מבלי לשנות את הכללים העסקיים או להשפיע עליהם באיזהשהוא אופן.
4. Independent of Databases, Libraries
   בלתי תלוי במסד הנתונים. 
   זה לא משנה אם ה DB שנבחר הוא ראלציוני, כמו Oracle או SQL Server, אתה יכול להחליף אותו ב DB דוקומנטי כמו Mongo, BigTable, CouchDB, HBase או משהו אחר. 
   business rules אינם כבולים לסוג ו.או תצוגת מסד הנתונים.
5. Independent of any External Agency (Security, scheduling,  etc)
   בלתי תלוי בשום שירות – agency חיצוני
   

למעשה הכללים העסקיים שלך פשוט לא יודעים שום דבר על העולם החיצון, על הספריות, הפריימוורק, פלטפורם כזה או אחר, tools & drivers שמשתמשים בתוכנה, חבילות חיצוניות ועוד.
Core Layers מבודדים לחלוטין מהעולם החיצון.

ואז, כל שינוי גרסה בתלויות, או הפסקת תמיכה בפיצ'ר מסויים, או מעבר טכנולוגי כזה אחר, מצמצם את רמת ההשפעה שלו לשכבות העליונות בלבד, העוטפות את שכבות ה pure code – business rules.

5 העקרונות הראשונים של הארכיטקטורה הם עקרונות ה SOLID. הם class level principles.
ויש כנגדם component level principles, שעוקבים-משקפים את ה SOLID principles, אבל חלים ברמת רכיב/קומפוננטה (groups of related classes)

ב Clean Architecture מתבססים על ההנחה ש:
These business rules tend to be fairly stable since you are not likely to change the essence of what your app does very often.

Architecture Layers – Circles

התרשים הבא של Uncle Bob הוא ניסיון לשלב את כל הארכיטקטורות הנ"ל הללו ברעיון חד פעמי.

• The Dependency Rule
  המעגלים מייצגים תחומי תוכנה שונים –  different areas of software. באופן כללי, ככל שאתה הולך רחוק יותר, כך תגיע לרמה גבוהה יותר של התוכנה.
  המעגלים החיצוניים הם מנגנונים. המעגלים הפנימיים הם policies.
  הכלל הקובע שגורם לאדריכלות זו לעבוד הוא כלל התלות . כלל זה אומר שתלות בקוד המקור יכולה להצביע רק פנימה . שום דבר במעגל פנימי – high-level modules – לא יכול לדעת משהו על משהו במעגל חיצוני – low level modules.
  בפרט, אסור להזכיר את השם של משהו שהוכרז במעגל חיצוני על ידי הקוד במעגל הפנימי.
  זה כולל פונקציות, classes, variables, או כל entity תוכנה בשם אחר.
  לסיכום – כל המודולים צריכים להיות תלויים ב Abstractions, השכבות הפנימיות שבנויות בצורה מופשטת ביותר.
  Details כלומר הפרטים החיצוניים כמו ה WEB או ה DB צריכים להיות תלויים ב Abstractions אבל Abstractions לא תלויים ב Details.
  
  באותה מידה, אין להשתמש ב data formats המשמשים במעגל חיצוני, במעגל פנימי.
  במיוחד אם תבניות אלה נוצרות על ידי framework במעגל חיצוני. אנחנו לא רוצים שמשהו במעגל חיצוני ישפיע על המעגלים הפנימיים.
  איך? באמצעות Dependency Injection!
  
• Entities (Enterprise Wide Business Rules or Business  Objects of a Single Application)
  ישויות אלו הכללים עסקיים הכלל ארגוניים והם עוטפים encapsulate את הכללים הכלליים וה high-level ביותר בארגון.
  ישות יכולה להיות an object with methods, או סט של data structures and functions.
  זה לא משנה מה רק הם אמורות להיות בנויות בצורה מופשטת, כלל ארגונית, בצורה כזאת שיוכלו לשמש אפליקציות נוספות בארגון, בין אם קיימות ובין אם במחשבה על העתיד ועל הייתכנות של הקמת שירותים נוספים בארגון.
  
  הם נוטים פחות להשתנות כאשר משהו חיצוני משתנה. לדוגמא, לא היית מצפה שאובייקטים אלה יושפעו משינוי page navigation, or security.
  שום שינוי תפעולי, אקטיבי ביישום מסוים לא אמור להשפיע על Entities layer.

• Use Cases (Application Specific Business Rules)
  התוכנה בשכבה זו מכילה Business Logic.
  בשכבה זו יש את הלוגיקה העסקית של ה use cases של המערכת.
  תפקידם של ה Use cases שנכתבים בשכבה זו, לנטר את הזרימה של ה data flow אל ומה entities, ובעצם מנחים את אותם entities להשתמש ב business rules כדי להשיג את המטרות של כל מקרה השימוש.
  איננו מצפים ששינויים ברובד זה ישפיעו על הישויות – entities. אנו גם לא מצפים כי שכבה זו תושפע משינויים ב externals כמו הדאטהבייס, ה UI – ממשק המשתמש או כל משאב חיצוני אחר.
  
  עם זאת, אנו כן מצפים ששינויים בתפעול התוכנה, ישפיעו על מקרי השימוש ובעצם על התוכנה בשכבה זו. כלומר אם details  של use-case משתנים, אז קוד כלשהו בשכבה זו בהחלט יושפע. אך עדיין השינוי יוכל להיתקל במעגל הבא במקרה שהשינוי לא משפיע הלאה, והוא שינוי פנימי בלוגיקה העסקית בלבד.
  
• Interface Adapters (Presenters, Controllers, Gateways, etc)
  אלו בעצם boundaries בין שכבות ה  Frameworks and Drivers לביןUse Cases ודומיין, ובכך הם גורמים ששכבת היישויות וה Use Cases לא יצטרכו לדעת שום דבר על שכבת ה Frameworks.
  זה אומר שה UI, database  תלויים ב business rules, אבל ה business rules לא תלויים ב UI או ה database.
  התוכנה בשכבה זו היא set של מתאמים – adapters שתפקידם להמיר בקשות מהמעגלים החיצוניים יותר לפנימיים.
  וכן להמיר את הנתונים מהפורמט הנוח/המתאים ביותר ל use cases & entities לפורמט הנוח ביותר עבור external agency כלשהי כמו מסד הנתונים או ה Web.
  באופן דומה, עבור whatever persistence framework כלומר דאטהבייס, הנתונים מומרים בשכבה זו, מהצורה הנוחה ביותר עבור use cases & entities, ל form הנוח ביותר עבור ה persistence framework – מסד הנתונים.
  
  שום קוד במעגלים הפנימיים יותר לא אמור לדעת שום דבר על בסיס הנתונים.
  אנחנו צריכים להגביל את כל המודלים או מימושים שונים וכולי שקשורים למסד הנתונים, לשכבה זו.
  כמו כן בשכבה זו נמצא כל adapter  אחר הדרוש להמרת נתונים מצורה external  כלשהי, כגון external service, לצורה הפנימית המשמשת את מקרי השימוש והישויות.
  
  בשכבה זו יהיו החלקים הבאים:
  – איחזור ושמירת נתונים ממספר מקורות (ומסדי נתונים, התקני רשת, מערכת קבצים, צד שלישי וכן הלאה).
  – הגדרת interfaces הדרושים להם כדי ליישם לוגיקה כלשהי כלשהו.
  – ספק של נתונים או כמה ספקים שונים יממשו את ה interfaces האלו, כך כמובן ב Use Cases לא ידוע מאיפה ואיך הנתונים מגיעים.
  – מימוש ה interfaces  שהוגדרו בשכבת ה Use Cases.
  – כאן יש את הדרכים לקיים אינטראקציה עם האפליקציה, ובדרך כלל זה איזשהו delivery mechanism (for example: REST APIs, scheduled jobs, GUI, other systems)
  – Triggering של use case והמרת את התוצאה לפורמט המתאים החוצה, ל delivery mechanism.
  
• Frameworks and Drivers (MVC / Android Framework, Web, etc)
  השכבה החיצונית ביותר מורכבת בדרך כלל מ UI, database, web APIs, frameworks, file systems, web services וכו'.
  בדרך כלל לא כותבים בשכבה זו הרבה קוד מלבד קוד דבק המתקשר communicates למעגל הבא פנימה.
  שכבה זו היא המקום אליו כל הפרטים מגיעים.
  הWEB הוא פרט. הDB הוא פרט.
  אנו שומרים את הדברים האלה outside , כי שם הם יכולים להזיק מעט, הכי פחות  ואז כמובן מקשרים אותם פנימה עם adapters.
  אלו הדברים שיותר שכיחים להשתנות מאשר השכבות הפנימיות.
  למשל יותר שכיח שתשנה איך הכפתור נראה ואיפה, מאשר איך ההלוואה מחושבת באפליקציה.
  בשירות סרבר, ה WEB למשל יכול להיות gateway entry point – api layer של ה service שכתבנו.
  ובאפליקציית אנגולר או ראקט או כל אפליקציה על פרייומוורק כלשהו, ה repository יהיה השירות בצד סרבר שכתבנו, והweb יהיה שכבת הקומפוננטות שמנהלות את ה GUI
  
  שכבה זו תלויה ב interfaces שמוגדרים בשכבה שפנימית לה – interface adapters. ורק דרכם היא מתקשרת פנימה אל ה use cases.

זה הופך את זה ל plugin architecture.
זה לא משנה אם הUI  הוא  web interface, a desktop app, a mobile app
זה לא משנה אם הדאטה מאוחסן ע"י SQL or NoSQL  או בכלל בcloud. שכבת היישויות והלוגיקה העסקית אדישות לכל זה.

מה שעושה את תהליך שינוי/עדכון בתשתיות infrastructures אפשרי ומאוד קל.

רק ארבעה מעגלים?

לא, אין כלל שאומר שתמיד חייבים להיות רק לארבעה האלה. עם זאת, יש כלל שחל תמיד והוא כלל התלות – Dependency Rule. שזה אומר שתלות בקוד המקור Source code – מכוונת תמיד פנימה.

כשאתה נע פנימה רמת abstraction  עולה.
המעגל החיצוני ביותר הוא איזהשהוא פרט ממשי, low level. וככל שאתה עובר פנימה, התוכנה הולכת ונהיית יותר abstract ועוטפת – את ה policies ברמה היותר גבוהה.
המעגל הכי הפנימי הוא הכי generic.

Implementation

בתרשים אפשר לראות flow של זרימת בקשה ממשתמש לאפליקציה שבנינו, וסימונים היכן נמצאת כל שכבה של הארכיטקטורה.

תמונה מתוך המצגת - תרשים זרימה מתוך הספר של בוב - סימוני השכבות ב אותיות A, B, C, D

תמונה מתוך המצגת - עקרון התלות - דיאגרמה

Advantages

• Testability
  ברגע שכל חלק וכל שכבה באפליקציה מושתתת על עיקרון הפרדת התלות, ולא גורמת לאיזה שהוא side-effect, משימת הבדיקות הופכת להיות קלה והרבה יותר convenient.
• High Cohesion
  A sign for Low Coupling
  לכידות גבוהה בקוד, קשר בין הדברים שהקוד מטפל – סימן לצמידות נמוכה, רמת התלות של הקוד נמוכה כיוון שהכול קשור.
  מונע מקרים שבהם יש classes שמקבלות http request, מביאות את הדאטה ממסד הנתונים, שומרות ב cache וגם מחזירות תגובה למשתמש.
• Reusable UseCases
  שכבה זו ניתנת לשימוש חוזר במידת הצורך, בין אפליקציות נוספות בארגון מכיוון שאינה תלויה במשאב חיצוני
• Suitable for all
  הארכיטקטורה מתאימה לכל שפה, טכנולוגיה, פלטפורמה.
• Multiple projects can share layers
  את השכבות המופשטות כמו הישויות והמקרי שימוש.
• Easier to implement
  פונקציונאליות כמו caching, storage, etc.
• Multiple Presentation patterns
  ניתן לממש כמה שכבות פרזנטציה שונות לאותה האפליקציה
• Blocks logic everywhere
  יש הגדרה ותיחום מדויק לכל פונציונאליות שרוצים להוסיף, לאיזו שכבה זה שייך

Disadvantages

Over-Engineering, perhaps? / Boilerplate code

בארכיטקטורה יש לא מעט שכבות. וצריך לכתוב קוד שמחבר ביניהם.
עיקרון ההפרדה בין תלויות גורם לצורך לכתוב הרבה קוד דבק, הרבה עטיפות לקוד שאולי היה פשוט יותר בלעדי כל ההפרדה הזאת.

יש גם הרבה duplicates בקוד, למשל של מודלים. יש את המודלים מופשטים עבור כלל הארגון, וכמסתבר יש גם מודלים ספציפיים לאפליקציה / פריימוורק או בשכבת ה DB.
קריאות הקוד אומנם נחשבת לעתים לחשובה לא-פחות מביטול כפילויות בקוד. אך השאלה כמה efforts יש להשקיע ומה נקבל בתמורה.

אם ניקח שירות micro-service קטן, ללא צורך ב WEB, שמטפל בדומיין מסויים ככה ששכבת ה entities הכלל ארגונית הופכת למסרבלת ואולי לממש מיותרת. השירות יכל להיכתב ב2 שכבות מקסימום.

או ארגון שיודע בוודאות שהסיכוי להחלפה טכנולוגית מאוד קטן. אם כי הוא משתמש בקומפוננטות פנימיות, ספציפיות בלבד, או מכל סיבה אחרת.

וכמובן אפליקציות קטנות, אנחנו מנסים לבנות תשתית לכאורה perfectly engineered עבור משהו שאולי ייזרק לפח, האפליקציה לא תהיה רלוונטית, כמות הזמן שהושקעה לא אפשרה לספק תוצאות מידיות וכן הלאה.

ראיתי ב StackOverFlow דוגמא נחמדה של מישהו שכתב כך:
"תן רכב אוטומובייל מהונדס בשלמות לילד בן 5, שביקש תלת אופן, ואתה יכול להתווכח שזה over engineered.
Clean Architecture זה לא one size fits all. זה נותן לך את הגמישות ואת הכוח, אבל במחיר עלות של מאמצי אקסטרה.
זה תלוי בך בלבד להחליט מתי אתה צריך את זה.
זה נותן לך את הגמישות שבאה מכך שאתה מבטא רק את הצורך האמתי שלך מה framework,
וכך לעשות חיים קלים יותר לאחרים שבאים להחליף את הפריימוורק או לתקן אותו כאשר יש breaking changes.

NOTICE:  אם לא אכפת לך מכל זה בנקודת הזמן הנוכחית – שום דבר לא יכול לעשות את זה כדאי. פשוט תקראו לזה "technical debt" והמשיכו הלאה"

Steep learning curve

עקומת לימוד תלולה – מימוש ידרוש זמן ומאמץ ניכר, כלומר הארכיטקטורה לא מאפשרת לימוד מהיר ותפעול יעיל לאחר זמן קצר. יש הרבה קונספטים תוך כדי עבודה שעולים צריך לחקור אותם בשביל לחלק את השכבות כמו שצריך.

אפשר לראות ב StackOverFlow כמות נכבדת של שאלות תאורתיות או יישומיות שעלו למתכנתים תוך כדי ניסיון לעקוב אחרי כללי הארכיטקטורה.

Main Entry Point & IOC

ה Inversion of Control (IoC) וה Dependency Injection (DI) patterns הם נועדו במטרה אחת: בשביל להסיר תלויות בקוד.

למשל, פונקציות ספרייה של JS כמו "map", "flatMap" הם מימושים של IoC.

עיקרון ה IoC עוזר ב designing loosely coupled(מחובר באופן רופף) classes מה שעושה אותם testable, maintainable and extensible.

נעקוב לפי הכלל הבא

1. Separate what-to-do part from when-to-do part.
2. Ensure that when part knows as little as possible about what part; and vice versa.

IoC הוא מושג כללי כלומר במקום שהאפליקציה תקרא למימושים שסופקו ע"י ספרייה או toolkit כלשהם,
, ה framework יקרא למימושים שסופקו ע"י האפליקציה.

וכאן תבנית זו באה לעזרתנו. כאשר משתמשים ב DI (Dependency Injection), תלוי בכל שפה או פריימווק מהו המימוש המדוייק אבל כמעט תמיד מחוייב להנגיש את ה binding בין כל interface לבין המחלקה שתממש אותו.

ב .NetCore 3 הדבר מתבצע ע"י רישום כל השירותים שהאפליקציה תצטרך להזריק במחלקה שנקראת StartUp.cs:

services.AddSingleton<IApiInfoService>(new ApiInfoService(Configuration));

הבעיה שנוצרה כאן שנשבר לנו עיקרון התלות, מכיוון שברמת ה entry point של האפליקציה אנחנו צריכים להוסיף dependencies לכל השכבות בפרוייקט כדי ליצור את ה binding הנ"ל.

פיתרון לדוגמא יכול להיות מבוסס IOC – כל שכבה מחצינה את ה binding לשירותים הספציפיים שלה, ב extension method.
ובפרויקט אחד חדש שניצור, הוא יהיה תלוי בכל השכבות, ורק שם נקרא לכל הפונקציות האלו, ובעצם ניצור את ה bindings עבור מנגנון ה DI.

Project Template Example

Note

יש הרבה בלבול בין הארכיטקטורות, ובמיוחד עם Onion Architecture ואם תחפשו template של פרוייקט לדוגמא שעוקב במלואו אחרי עקרונות ה Clean Architecture יהיה לכם די מסובך למצוא. מסתבר שתמצאו ערבוב בין מושגים.

Design Patterns & Libraries

שמה כאן כמה שמות של ספריות וכולי, שיצא לי לחקור כחלק מהטמעת הארכיטקטורה. הם נותנים פוש לעקרונות הארכיטקטורה וסתם עובדים טוב ביחד.

_▸ DDD

_▸ CQRS

_▸ Mediator – MediatR in NuGet

_▸ Validation with FluentValidation

_▸ Object-Object Mapping with AutoMapper

_▸ Data access with Entity Framework Core

_▸ Open API with NSwag

_▸ SignalR

_▸ DIP, DI, IOC

Downloads

1. Presentation file:

Presentation: Clean Architecture Ester Kaufman – Download

2. Recording video:

RESOURCES / Podcasts & Blog Series

▸ “The Clean Architecture” by Uncle Bob

▸ Clean Architecture with .NET Core: Getting Started – Jason Taylor

▸ Clean Architecture Solution Template

▸ Clean Architecture with ASP.NET Core 3.0 (NDC Sydney 2019)

▸ Rules to Better Clean Architecture

▸ Clean Architecture Dev Superpowers Tour

▸ Clean Architecture 2 – day Workshop

▸https://github.com/badoo/Chateau

▸Live Stream Recordings Working on Clean Architecture

▸DotNetRocks Podcast Discussion with Steve "ardalis" Smith

▸Fritz and Friends Streaming with Steve "ardalis" Smith