A talk I gave at the WaterfordTech meetup on 26/07/2017. The talk focusses on the problem of writing good code, why do we find it so hard? Once we understand the problem, we can look at solutions, and then we focus on how a clean architecture can be applied to give us that first step of clarity that leads to good code. The code used in the examples can also be found here (use arrow keys to navigate pages) https://barryosull.github.io/clean-architecture-code.html

1. Cleaning up your Codebase
With a Clean Architecture
Expressing complexity through separation of concerns

2. Who am I?
Lead Developer and Solutions Architect for
DynamicReservations
Writing web apps professionally for 12 yrs
DDD and EventSourcing fanatic (I will talk for hours)
Recovered Architecture Astronaut
Organiser of PHPDublin @barryosull
barry@tercet.io
http://dev.to/barryosull
http://barryosullivan.me

3. Todays Talk
Why is Writing Good Code so Hard?
What is a Clean Architecture?
How do you apply a Clean Architecture?

4. Why Writing Good Code is so Hard

5. The Status Quo
1 YEAR
LATER
OR
OR

6. The Core of the Problem
"Our codebase is really messy and hard to
use. How do we clean it up?"
"Simple. We just need to refactor it, move code
into objects, separate the concerns."
"Ok, great!
How do we do that?"
"Easy. We'll use design patterns and follow the
SOLID principles. Job done."

7. Why doesn’t this work?
Only talks about these
Never talks about these
“How do you make things?”

8. Learning the patterns isn't enough
?
?
?
?
?
?
?
?
?
?
?
?

9. Wrong design pattern makes it worse
Wrong
Patterns
WHY?!!

10. What is “Design”?
Design
Is an
Action
Problem
Research
Solution
Implementation
Evaluation
Definition

11. What is a Clean Architecture

12. Clean Architecture
Business Objects
(User/Email/ProfileImage)
Usecases
(CreateUser/SetProfileImage)
Controllers
(UserController/ImageController)
Technology Details
(MySQL/Redis/Filesystem/Framework)
NB: Layers can only reference concepts from their layer
and inners layers. They can never point at outer layers.

13. Why is it layered this way?

14. Business Requirements Change
“A user can upload a profile picture”
New User functionality
New Usecase
New Controller
Update datamapper and add
DB migration

15. Application Requirements Changes
No change to Users
Add a new Usecase
Add a new Controller
Add a new Twilio Service
“A user can change their email address via text ”

16. Implementation Requirements Change
“User Signup is slow, because checking email uniqueness takes ages, it should be faster”
No business logic changes
Usecases stay the same
Controllers stay the same
Redis used as a faster
datastore in implementation

17. Applying a Clean Architecture

20. Too many concepts/different languages

21. Separating the Concerns
Isolate details
● Config
● Flysystem
● AWS S3
● Eloquent ORM
Replace with abstractions
● Make implicit concepts explicit

26. Why is this better?
● Easier to read
● Easier to test
● Patterns used effectively
● Loose coupling
○ Easier to change implementation

27. Why is this worse?
● Larger Codebase
● Design isn’t free, it takes time
class Room{
const ELEPHANT = true;
}

28. Practice makes Perfect Better

29. When to do it

30. Conclusion
Q: Why is Writing Good Code so Hard?
Because we don’t define the problem our architecture is solving
Q: What is a Clean Architecture?
A model for decoupling code through common categories to make
complexity and changes easier to manage
Q: How do you apply a Clean Architecture?
By removing outer layer language from inner layers, making each layer
simpler, consistent and concise

31. Thank you
Question Time! More Material
● Implementing Domain Driven Design by
Vaughn Vernon
● Uncle Bob’s “Clean Architecture” Article
(1st google result)
● @barryosull
(I tweet/write/talk about this stuff a lot)
● http://dev.to/barryosull
● http://barryosullivan.me
● Or just talk to me afterwards!