Clean Architecture

Implementing Scalable Development

SoftUni Team
Technical Trainers
Software University
https://softuni.bg
Table of Contents

1. Clean Architecture Key Concepts

2. Domain Layer
3. Application Layer
4. Infrastructure Layer
5. Presentation Layer
6. Tests

2
Questions

sli.do
#micro-ddd
3
Terminology
History Lesson
 Domain-Driven Architecture is also known as
 Hexagonal Architecture
 Ports & Adapters
 Onion Architecture
 Everything Points Toward
The Domain
 Clean Architecture
 The “Latest” Installment

5
Terminology Disclaimer
 Interactors
 Represent use cases
 The business logic which interacts with the entities
 Uses interfaces and no implementation details
 In other words – factories, repositories, gateways
 Boundary
 Responsible for translating data from one layer to another
 Uses ports, models or results
6
Clean Architecture
 Domain and use cases are important
 Infrastructure and presentation are details
 Independent of frameworks
 Independent of UI
 Independent of database
 Independent of anything external
 Testable

7
Clean Architecture
 Pros
 Focus on business logic
 Less coupling
 Allows DDD
 Cons
 Requires more though
 Initial higher cost

8
Key Concepts
Key Concepts
 Domain contains enterprise-wide logic and types
 Application contains business-logic and types, uses
interfaces
 Infrastructure contains all external concerns, uses
implementations
 Presentation and Infrastructure depend only on Application
 Infrastructure and Presentation components can be
replaced with minimal effort
 We pass data between layers with input/output models
10
Design

11
Design

12
Domain Layer
Domain Layer
 Entities, Value Objects, Enumerations, Exceptions,
Domain Logic, Events
 Don’t use data annotations
 Create custom domain exceptions
 Initialise all collections & use private setters
 Consideration: internal constructors
 Consideration: public factories only for the aggregate roots

14
Application Layer
Application Layer
 Interfaces, Models, Logic, Commands & Queries, Validators
 Use CQRS – commands & queries – simple and scalable
 Easy to add new features
 Easy to maintains, one change effect one query
 Add MetiatR and save yourself from too much classes
 Application layer becomes just input/output objects
 Easy to add additional behaviour before or after each request
caching, logging, validation

16
Application Layer
 Using CQRS + MediatR simplifies your overall design
 MediatR simplifies cross cutting concerns
 Fluent Validation is useful for all validation scenarios
 AutoMapper simplifies mapping and projections
 Independent of infrastructure concerns
 Specification pattern for complex queries

17
Input/Output Models
 Application layer should always use input/output models to
communicate with the outer world
 Do not inherit or reference domain models
 Do not reuse the same input model for multiple use cases
 Use base classes where appropriate
 Try to reuse the output models as much as possible
 Define only properties, which are needed for the use case
 Add only formal validation, do not include complex domain-specific logic
 Never auto-map input models to domain entities, use factories & domain
methods

18
Infrastructure Layer
Infrastructure Layer
 Persistence, Identity, File System, System Clock, API
Clients, Payments, E-mails, Etc.
 Independent of the database
 Use Fluent API configuration over data annotations
 Prefer conventions over configuration
 Automatically apply all entity type configurations
 No layers depend on Infrastructure layer, e.g.
Presentation layer
20
Infrastructure Layer
 What About Repository Pattern?
 It depends, but keep in mind:
 EF Core insulates your code from database changes
 DbContext acts as a unit of work
 DbSet acts as a repository
 EF Core has features for unit testing without repositories
 Personally, I do not use it anymore, except when I want
to protect aggregate roots from the other layers
 Considerations: the Specification pattern
21
Presentation Layer
Presentation Layer
 Angular, React, Vue, Web API, Razor Pages, MVC, Web
Forms
 Controllers should not contain any application logic
 Create and consume well defined models
 Bonus:
 Open API bridges the gap between the front end and
back end
 NSwag automates generation of Open API specification
and clients 23
Tests
Tests
 Domain layer – unit tests – domain logic
 Application layer – unit tests – commands & queries
logic
 Infrastructure layer – integration tests – each testable
component
 Web layer – integration tests – every request
 Prefer using the same project for tests, development is
easier
25
Summary

 Clean
 … Architecture Key Concepts
 Domain
 Layer
…
 Application Layer
 …
 Infrastructure Layer
 Presentation Layer
 Tests

26
Questions?

© SoftUni – https://about.softuni.bg. Copyrighted document. Unauthorized copy, reproduction or use is not permitted.
Trainings @ Software University (SoftUni)
 Software University – High-Quality Education,
Profession and Job for Software Developers
 softuni.bg, softuni.org
 Software University Foundation
 softuni.foundation
 Software University @ Facebook
 facebook.com/SoftwareUniversity
 Software University Forums
 forum.softuni.bg
 2
License

 This course (slides, examples, demos, exercises, homework,

documents, videos and other assets) is copyrighted content
 Unauthorized copy, reproduction or use is illegal
 © SoftUni – https://softuni.org
 © Software University – https://softuni.bg

29