Clean architecture

Clean architecture

• 1.
  C l ea n A r c h i t e c t u r e T r a v i s F r i s i n g e r @ t m f r i s i n g e r
• 2.
  ABOUT ME - I havewritten software for over 25 years - 17 of those professionally. - Owner of StoneAge Technologies LLC - Fractional CTO - Trainer - Speaker - Using Clean Architecture for over 3 years. - Started using it when there was mainly only Uncle Bob’s blog post about it. - Used it on over 6 projects learning lessons with each implementation. - I maintain a few nuget packages that simplify the boiler plate code of Clean Architecture for .Net and .NetCore
• 3.
  Overview C l ea n A r c h i t e c t u r e MVC Migration TipsElements of Good Architecture The Architecture How I evaluate an architecture Examination of the whole and its parts How to refactor your existing architecture Brief History What came before
• 4.
  • Handle constantchange while ensuring maintainability of code base • Easily facilitate teams working together • Avoid ‘god’ classes • Quality Why do we need architecture? C l e a n A r c h i t e c t u r e
• 5.
  • Testable • EnablesTechnical Agility • Independent of Frameworks • Independent of UI • Independent of Database • Changes are easy to accommodate • Easy to deploy • Easy to implement Elements of Good Architecture C l e a n A r c h i t e c t u r e
• 6.
  - Layered - MVC -Microservices Other Patterns Brief History C l e a n A r c h i t e c t u r e Design Principles - SOLID - DRY
• 7.
  SOLID C l ea n A r c h i t e c t u r e • Single Responsibility • A class should have only one reason to change • Open Closed • Software entities (classes, modules, functions, etc.) should be open for extension but closed modification • Liskov Substitution Principle • Subtypes must be substitutable for their base types • Interface Segregation • Clients should not be forced to depend on methods they do not use • Dependency Inversion • A. High-level modules should not depend on low-level modules. Both should depend on abstractions. • B. Abstractions should not depend on details. Details should depend on abstractions.
• 8.
  DRY C l ea n A r c h i t e c t u r e • Don’t Repeat Yourself • Every piece of knowledge must have a single unambiguous, authoritative representation in the system. • Often this principle is miss- understood with developers building abstractions for things that look similar, but represent different concepts. It is only repeated if the code represents the same concept. That is the same sentence can be used to describe what it represents.
• 9.
  Layered C l ea n A r c h i t e c t u r e UI Business Logic Persistence • Components within the layered architecture pattern are organized into horizontal layers • Each layer performing a specific role within the application • Request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one. Database
• 10.
  MVC C l ea n A r c h i t e c t u r e • Separates internal representation of information from how the information is presented and accepted from the user. • Model – Manages data, logic and business rules • View – What the user sees • Controller – Takes input and converts it to operation for the model or view Dependency Graph Over Time
• 11.
  MVC + Repository Cl e a n A r c h i t e c t u r e • MVC with the addition of decoupled data storage • Allows developer to apply S and D of SOLID • Increases testability of architecture
• 12.
  Microservices C l ea n A r c h i t e c t u r e • Quickly gaining ground in the industry as a viable alternative to monolithic applications and service-oriented architectures. • Each component of the microservices architecture is deployed as a separate unit or service component. • Service components, which can vary in granularity from a single module to a large portion of the application • All the components within the architecture are fully decoupled from one other and accessed through some sort of remote access protocol https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch04.html
• 13.
  Why Clean Architecture Cl e a n A r c h i t e c t u r e “We should think about our application as a group of use cases that describe the intent of the application and a group of plugins that give those use cases access to the outside world.” Uncle Bob
• 14.
  The Architecture C le a n A r c h i t e c t u r e
• 15.
  The Architecture C le a n A r c h i t e c t u r e Presenters Repositories
• 16.
  Data Flow C le a n A r c h i t e c t u r e Entry Point Presenter Use Cases Entities Repositories Data Source
• 17.
  Dependency Rule C le a n A r c h i t e c t u r e Entry Point Presenter Use Cases Entities Repositories Data Source Entry Point Presenter Composition Layer Domain Layer Data Layer Use CasesEntities Interfaces Repositories Network Data Source File System Data Source Use Case Inputs
• 18.
  Dependency Inversion C le a n A r c h i t e c t u r e Use Case Repository Interface Depends on Repository Interface Implements Interface Injected into Use Case via IoC container
• 19.
  Data Models C le a n A r c h i t e c t u r e Entities Input Model Mapper Composition Layer Domain Layer Data Layer Entities Repositories Data Model Mapper
• 20.
  Power of Presenters Cl e a n A r c h i t e c t u r e Use Cases Entities Repositories Data Source Output Presenter Composition Layer Domain Layer Use Case Interface Use Case depends on presenter interface across boundary Creates concrete presenter to pass into use case depending on needs to entry point Use Case isVoid return. Relies on the presenter to return data
• 21.
  Testing C l ea n A r c h i t e c t u r e Entry Point Composition Layer Use Case Mock Repository Mock Presenter External Mocks Entities (Http, File System) Test Server
• 22.
  Testing C l ea n A r c h i t e c t u r e Use Case Test Presenter Domain Layer Services Repository Entity Test Data Services I find often I pull services back onto the entity where the data sits.This means I need to test them. There may still be other 3rd party services the entity needs to do it’s job hence why they are created as part of the testing process. Testing DB Context Make use ofTest Data Builders to populate this and allow for re-use across test. Config If making use of more then one repository. Mock our the non-critical repositories to pass through in the test.
• 23.
  Testing C l ea n A r c h i t e c t u r e Repositories Data Layer Repository Services Testing DB Context Config
• 24.
  - Well Structured -Modular - Very Testable - Independent of Frameworks and Tools - Maintainable Benefits - Boiler plate code - Not suitable for all projects - Multiple ways to implement Issues Issues and Benefits Y o u r G r e a t S u b t i t l e H e r e
• 25.
  Tips for movingfrom standard MVC to Clean Architecture MVC MIGRATION - Use test to drive the process - Create repositories for data operations - Inject the repositories into your controller - Model Domain Entities - Do not have controllers take Domain Entities instead they should take an Input TO and transform to Domain entity - Have repositories accept and return Domain entity - Migrate service logic onto the related Domain Entity - Create Use Cases to - Use Repositories - House remaining logic in Controller - Coordinate Entities - If need be create Composite Use Cases to allow for re-use of common business logic.
• 26.
  T h an k Yo u @ t m f r i s i n g e r
• 27.
  S o ur c e a n d P a c k a g e s https://github.com/T-rav/Reference-CleanArchitecture-DotNet (https://bit.ly/2FwXxsK) https://www.nuget.org/profiles/T-rav (https://bit.ly/2HDc5JJ)
• 28.
  References C l ea n A r c h i t e c t u r e • https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html • https://github.com/mattia-battiston/clean-architecture-example • https://proandroiddev.com/intro-to-app-architecture-922b392b21b2 • https://www.sitepoint.com/model-view-controller-mvc-architecture-rails/ • https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch04.html • https://www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/ • https://medium.freecodecamp.org/a-quick-introduction-to-clean-architecture-990c014448d2 • https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-615ffdd79e29