The document discusses Clean Architecture, an approach for building maintainable and testable code. It presents four main principles: 1) limit dependencies between modules, 2) introduce boundaries between modules, 3) have dependencies point towards abstractions, and 4) inject dependencies. The architecture separates entities, business rules, use cases, interfaces, and drivers/frameworks. This independent, layered structure makes the code independent of frameworks and databases, and easier to maintain and evolve over time.

1. CLEAN
ARCHITECTURE
Flavius Ștef, Syneto
Timișoara, Oct. 2018

2. CODING IS HARD
ENOUGH ALREADY
Programming language
Libraries
Front-end framework
Back-end framework
AWS or Azure
sync vs async
trees and graphs
ML
...2

3. Why also bother with architecture?
Layered, MVC, REST, Microservices...
3

4. TWO PHASES FOR EACH CODEBASE
4
Puberty
MVP, 0.9beta, 1.0
Code familiarity
Progress
Maturity
Value delivery
Speed
Quality
Architecture
matters the
most here

5. ARCHITECTUREtries to solve an economic set of needs,
not a technical one
5

6. Average codebase life:
10 years
6

7. SYNETO ARCHITECTURE NEEDS
Steady Velocity
In the marketplace
High quality
Limited margin for errors
Easy onboarding
Of new team members.
Reuse components
As we build new features
Test automation
To catch errors fast.
Code readability
Change code with confidence.
7

8. YOUR NEEDS?
Reuse, automation, readability
Security
Scalability
Velocity
8

9. CLEAN ARCHITECTURE
By Robert “Uncle Bob” Martin
Code maintenance and evolution
9

10. 1.
MAINTAINABLE CODE
General principles

11. What gets in the way?
11

12. Dependencies
12

13. PRINCIPLE #1Limit dependencies
13

14. Encapsulation
All related code should be in the
same class/module.
LIMIT DEPENDENCIES
Cohesion
All code in the same
class/module should be related.
14
👍 👎

15. “every module or class should
have responsibility over a
single part of the functionality
provided by the software, and
that responsibility should be
entirely encapsulated by the
class.
-- Wikipedia (SRP)
15

16. SRP
16
# $ %

17. MODULE LEVEL
DEPENDENCY MANAGEMENT
▪ How do we group classes together?
▪ How do the dependencies point?
▪ Who creates the clases?
17

18. Big Ball of Mud
HOW DO WE GROUP CLASSES?
18
MVC / MVVM / MVP Layered
Controller
Model View
UI
Business
Database

19. PRINCIPLE #2Introduce boundaries between modules
19

20. Big Ball of Mud
DEPENDENCIES
20
MVC / MVVM / MVP Layered
Controller
Model View
UI
Business
Database

21. CLEAN ARCHITECTURE
21
Business
Logic
Application
Logic
Infrastructure
concrete abstract

22. PRINCIPLE #3Dependencies point in the direction of the abstraction
22

23. 23
SMTPSenderInvoiceGenerator
MailSenderInvoiceGenerator
SMTPSender

24. PRINCIPLE #4Inject dependencies
24

25. 25
class InvoiceGenerator {
private SMTPSender sender;
public InvoiceGenerator() {
sender = new SMTPSender();
}
}
// client
InvoiceGenerator g = new InvoiceGenerator();
interface EmailSender { public void sendEmail(); }
class SMTPSender implements EmailSender { ... }
class AWSEmailSender implements EmailSender { ... }
class CleanInvoiceGenerator {
private EmailSender sender;
public CleanInvoiceGenerator(EmailSender s) { sender = s; }
}
// client
CleanInvoiceSender s = new InvoiceSender(new SMTPSender());
CleanInvoiceSender s = new InvoiceSender(new AWSEmailSender());

26. MAINTAINABLE CODE PRINCIPLES
▪ Limit dependencies
▪ Introduce boundaries between modules
▪ Dependencies point in the dir. of the abstraction
▪ Inject dependencies
26

27. 2.
CLEAN ARCHITECTURE
Putting it all together

28. CHARACTERISTICS
1. independent of frameworks
2. testable
3. independent of the UI
4. independent of the database
5. independent of any external agency
28

29. “your business rules don’t know
anything at all about the
interfaces to the outside world.
-- R. Martin, Clean Architecture
29

30. 30
Entities
“VAT of 19% will be applied to all sold
items, except for books where VAT is 5%”
“You cannot power off a powered off VM
Enterprise Rules

31. 31
Entities
Enterprise Rules
Use Cases
Application Rules
“send a SMS to the client after we have
successfully approved his meal order”

32. 32
Entities
Enterprise Rules
Use Cases
Application Rules

33. 33
Entities
Enterprise Rules
Use Cases
Application Rules
Web
UI
Devices
DB
Frameworks & Drivers

34. 34
Entities
Enterprise Rules
Use Cases
Application Rules
Web
UI
Devices
DB
Frameworks & Drivers
Controllers
Interface Adapters

35. 35
public class App {
...
static void main(String[] args){
...
dbConn = new MysqlConnection(...); // framework
view = new HTMLView(...); //framework
repository = new MysqlRepository(dbConn); // interface adapter
controller = new Controller(getRequest()); // interface adapter
presenter = new Presenter(view); // interface adapter
useCase = new ListOrders(controller, repository);
useCase.addPresenter(presenter);
useCase.run();
...
}
...
}

36. 36
Entities
Use Cases
Web
UI
Devices
DB
Controllers
FLOW OF
CONTROL

37. 37
AN
EXAMPLE

38. 38
Entities
Use Cases
Web
UI
Devices
DB
Controllers
DEPENDENCIES

39. 3.
FINAL WORDS
A few tips and tricks and summary

40. TIPS
Analyze the investment
Clean architecture is not cheap
40
Use it with DDD and CQRS
It maps nicely
Don’t be too rigid
Figure out which rules can be broken
Spend time understanding the layers
What should go in infrastructure, app and domain

41. CLEAN ARCHITECTURE IS
ReadableTestable Reusable Evolvable

42. THANKS!
Any questions?
You can find me at:
@flaviusstef
flavius.stef@gmail.com
slideshare.net/fstef
42