Ad
More Related Content
What's hot (20)
Similar to Clean architecture with asp.net core (20)
Ad
Recently uploaded (20)
Ad
Clean architecture with asp.net core
- 1. Clean Architecture with ASP.NET Core STEVE SMITH ARDALIS.COM | @ARDALIS | [email protected] DEVIQ.COM
- 2. Learn More After Today 1) Pluralsight ◦ N-Tier Apps with C# http://bit.ly/PS-NTier1 ◦ Domain-Driven Design Fundamentals http://bit.ly/ddd-fundamentals 2) DevIQ ◦ ASP.NET Core Quick Start http://aspnetcorequickstart.com 3) Microsoft FREE eBook/Sample App ◦ eShopOnWeb eCommerce Sample https://ardalis.com/architecture-ebook 4) Contact me for mentoring/training for your company/team
- 3. Questions HOPEFULLY YOU’LL KNOW THE ANSWERS WHEN WE’RE DONE
- 4. Why do we separate applications into multiple projects?
- 5. What are some principles we can apply when organizing our software modules?
- 6. How does the organization of our application’s solution impact coupling?
- 7. What problems result from certain common approaches?
- 8. How does Clean Architecture address these problems?
- 9. How does ASP.NET Core help?
- 10. Principles A BIT OF GUIDANCE
- 12. Separation of Concerns Avoid mixing different code responsibilities in the same (method | class | project) The Big Three™ Data Access Business Rules and Domain Model User Interface
- 13. Separation of Concerns The Big Three™ Data Access Business Rules and Domain Model User Interface
- 15. Single Responsibility Works in tandem with Separation of Concerns Classes should focus on a single responsibility – a single reason to change.
- 17. Following Don’t Repeat Yourself… Refactor repetitive code into functions Group functions into cohesive classes Group classes into folders and namespaces by Responsibility Level of abstraction Etc. Further group class folders into projects
- 18. More Grouping Options to Explore Aggregates Features Bounded Contexts
- 20. Invert (and inject) Dependencies Both high level classes and implementation-detail classes should depend on abstractions (interfaces).
- 21. Invert (and inject) Dependencies Classes should follow Explicit Dependencies Principle: Request all dependencies via their constructor Make your types honest, not deceptive
- 22. Invert (and inject) Dependencies Corollary: Abstractions/interfaces must be defined somewhere accessible by: Low level implementation services High level business services User interface entry points
- 23. Make the right thing easy and the wrong thing hard. FORCE DEVELOPERS INTO A “PIT OF SUCCESS”
- 24. Make the right thing easy and the wrong thing hard. UI classes shouldn’t depend directly on infrastructure classes ◦ How can we structure our solution to help enforce this?
- 25. Make the right thing easy and the wrong thing hard. Business/domain classes shouldn’t depend on infrastructure classes ◦ How can our solution design help?
- 26. Make the right thing easy and the wrong thing hard. Repetition of (query logic, validation logic, policies, error handling, anything) is a problem ◦ What patterns can we apply to make avoiding repetition easier than copy/pasting?
- 28. Source: MSDN Website, 2001
- 31. Transitive Dependencies DB Data Access Layer Business Logic Layer User Interface Layer Everything Depends on the database
- 32. Domain-Centric Design AND THE CLEAN ARCHITECTURE Core Business Logic Everything Else
- 33. Domain Model Not just business logic, but also: A model of the problem space composed of Entities, Interfaces, Services, and more. Interfaces define contracts for working with domain objects Everything in the application (including infrastructure and data access) depends on these interfaces and domain objects
- 34. Clean Architecture Onion Architecture Hexagonal Architecture Ports and Adapters
- 37. Clean Architecture “Rules” 1. You do not talk about Clean Architecture.
- 38. Clean Architecture “Rules” 1. You do not talk about Clean Architecture.
- 39. Clean Architecture “Rules” The Application Core contains the Domain Model
- 40. Clean Architecture “Rules” All projects depend on the Core project; dependencies point inward toward this core
- 41. Clean Architecture “Rules” Inner projects define interfaces; outer projects implement them
- 42. Clean Architecture “Rules” Avoid direct dependency on the Infrastructure project (except from Integration Tests)
- 43. Clean Architecture Features Framework Independent ◦ You can use this architecture with ASP.NET (Core), Java, Python, etc. ◦ It doesn’t rely on any software library or proprietary codebase.
- 44. Clean Architecture Features Database Independent ◦ The vast majority of the code has no knowledge of persistence details. ◦ This knowledge may exist in just one class, in one project that no other project references.
- 45. Clean Architecture Features UI Independent ◦ Only the UI project cares about the UI. ◦ The rest of the system is UI-agnostic.
- 46. Clean Architecture Features Testable ◦ Apps built using this approach, and especially the core domain model and its business rules, are easy to test.
- 47. Refactoring to a Clean Architecture Best to start from a properly organized solution ◦ See http://github.com/ardalis/CleanArchitecture Next-best: Start from an application consisting of just a single project Most difficult: Large, existing investment in multi-layer architecture without abstractions or DI
- 48. The Core Project Minimal dependencies – none on Infrastructure. What Goes in Core: Interfaces Entities Value Objects Aggregates Domain Services Domain Events Exceptions Specifications Event Handlers
- 49. The Infrastructure Project All dependencies on out-of-process resources. What Goes in Infrastructure: Repositories EF (Core) DbContext Web API Clients File System Accessors Email/SMS Sending Logging Adapters System Clock Other Services Cached Repositories Interfaces
- 50. The Web Project All dependencies on out-of-process resources. What Goes in Web: Controllers Views ViewModels Filters Binders Other Services Razor Pages ApiModels BindingModels Tag/Html Helpers Or Interfaces
- 51. Sharing Between Solutions: Shared Kernel Common Types May Be Shared Between Solutions. Will be referenced by Core project(s). Ideally distributed as Nuget Packages. What Goes in Shared Kernel: Base Entity Base Domain Event Base Specification Common Exceptions Common Interfaces Common Auth e.g. User class Common DI Common Logging Common Guard Clauses
- 52. Guard Clauses? Simple checks for input that use common rules and exceptions. Nuget Package: Ardalis.GuardClauses (https://github.com/ardalis/GuardClauses) Example: public void ProcessOrder(Order order) { Guard.Against.Null(order, nameof(order)); // process order here }
- 53. Solution Structure – Clean Architecture Web Core Infrastructure Shared Kernel Unit Tests Functional Tests Integration Tests
- 54. Typical (Basic) Folder Structure
- 55. What belongs in actions/handlers? Controller Actions (or Page Handlers) should: 1) Accept task-specific types (ViewModel, ApiModel, BindingModel) 2) Perform and handle model validation (ideally w/filters) 3) “Do Work” (More on this in a moment) 4) Create any model type required for response (ViewModel, ApiModel, etc.) 5) Return an appropriate Result type (View, Page, Ok, NotFound, etc.)
- 56. “Do Work” – Option One Repositories and Entities 1) Get entity from an injected Repository 2) Work with the entity and its methods. 3) Update the entity’s state using the Repository Great for simple operations Great for CRUD work Requires mapping between web models and domain model within controller
- 58. “Do Work” – Option Two Work with an application service. 1) Pass ApiModel types to service 2) Service internally works with repositories and domain model types. 3) Service returns a web model type Better for more complex operations Application Service is responsible for mapping between web models and domain model. Keeps controllers lightweight, and with fewer injected dependencies.
- 60. “Do Work” – Option Three Work with commands and a tool like Mediatr. 1) Use ApiModel types that represent commands (e.g. RegisterUser) 2) Send model-bound instance of command to handler using _mediator.Send() No need to inject separate services to different controllers – Mediatr becomes only dependency.
- 62. Resolve Command w/Model Binding
- 63. Code Walkthrough
- 64. Resources Online Courses (Pluralsight and DevIQ) • SOLID Principles of OO Design http://bit.ly/SOLID-OOP • N-Tier Architecture in C# http://bit.ly/PS-NTier1 and http://bit.ly/PS-NTier2 • DDD Fundamentals http://bit.ly/ddd-fundamentals • ASP.NET Core Quick Start http://aspnetcorequickstart.com/ • Weekly Dev Tips Podcast http://www.weeklydevtips.com/ • Microsoft Architecture eBook/sample http://aka.ms/WebAppArchitecture