The document discusses principles of software architecture and design including: - Software architecture begins with code and the architect is still a programmer. - The SOLID principles are important for arranging code into well-designed components. - Clean Architecture specifies architectural patterns for separating concerns with layers and dependencies only pointing inward. This makes code independent and testable. - Other principles covered include component cohesion, reuse, stable dependencies, and abstraction. Overall the document provides guidance on best practices for clean and maintainable software architecture and design.

1. Clean Architecture
Robert Cecil Martin
A software architect is a programmer, and continues to be a
programmer
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=pd_sbs_14_t_0/145-8648759-3348529?_encoding=UTF8&pd_rd_i=0132350882&pd_rd_r=0b896974-0fab-47fa-8c15-e05db1fd2221
&pd_rd_w=LnRxS&pd_rd_wg=MVnWS&pf_rd_p=5cfcfe89-300f-47d2-b1ad-a4e27203a02a&pf_rd_r=D113M0BZHVN174TNY6XW&psc=1&refRID=D113M0BZHVN174TNY6XW

2. Software Architecture Begins With Code
A software architect is a programmer, and continues to be a programmer.

3. What is design and architecture?
Design -> Lower Level Architecture -> Higher Level
Wrong!

4. Product, Architecture and Software Development Team

5. What is
Abstraction?
Main goal is;
- To handle complexity by hiding unnecessary details from
user.
A Class can decide which data member will be visible to outside world
and which is not.
One more type of abstraction in C++ can be header files. For example,
consider the pow() method present in math.h header file. Whenever we
need to calculate power of a number, we simply call the function pow()
present in the math.h header file and pass the numbers as arguments
without knowing the underlying algorithm according to which the
function is actually calculating power of numbers.
Access specifiers are the main pillar of implementing abstraction in
C++. (public, protected, private)
Coffee Machine
https://stackify.com/oop-concept-abstraction/

6. Design Principles
If the bricks aren’t well made, the
architecture of the building doesn’t
matter much.
On the other hand you can make
substantial mess with well-made
bricks.
This is where the SOLID principles
come in.
Good software systems starts with
clean code
Single Responsibility Principle
Open Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

7. Single
Responsibility
Principle
“A class or module should have one, and only one,
reason to be changed”
“A module should be responsible to one, and only
one, actor”

8. Single
Responsibility
Principle

9. Single
Responsibility
Principle

10. Open Closed
Principle
“A software artifact should be open for extension
but closed for modification”
“Higher level components in that hierarchy are
protected from changes made to lower level
components.”
Behind the scene; “The OCP”
The goal is to make the system easy to extend
without incurring a high impact of change.
- Divide the system into components
- Arranging those components into a
dependency hierarchy that protects
higher-level components from changes in
lower level components

11. Open Closed
Principle
http://joelabrahamsson.com/a-simple-example-of-the-openclosed-principle/

12. Open Closed
Principle
http://joelabrahamsson.com/a-simple-example-of-the-openclosed-principle/

13. Liskov
Substitution
Principle Square Rectangle Problem
https://drive.google.com/file/d/0BwhCYaYDn8EgNzAzZjA5ZmItNjU3NS00MzQ5LTkwYjMtMDJhNDU5ZTM0MTlh/view

14. Interface
Segregation
Principle
https://dzone.com/articles/solid-principles-interface-segregation-principle

15. Interface
Segregation
Principle
https://dzone.com/articles/solid-principles-interface-segregation-principle

16. Dependency
Inversion
Principle
High-level modules should not depend on low level modules.
Both should depend on abstractions.
Abstractions should not depend on details. Details should
depend on abstractions.

17. What is
Architecture?
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

18. What is
Architecture?

19. What is
Architecture?
- Independence of Frameworks
- The architecture does not depend on the existence of
some library of feature laden software.
- Testable
- The business rules can be tested without the UI,
Database, Web Server, or any other external element.
- Independent of UI
- A Web UI could be replaced with a console UI, for
example, without changing the business rules.
- Independent of Database
- You can swap out Oracle or SQL Server, for Mongo,
BigTable, CouchDB, or something else.
- Independent of Any External Agency
- In fact your business rules simply don’t know
anything at all about the outside world.

20. Dependency
Rule
This rule says that source code dependencies can only point
inwards. Nothing in an inner circle can know anything at all
about something in an outer circle. In particular, the name of
something declared in an outer circle must not be mentioned by
the code in the an inner circle.
As you move inwards the software grows more abstract, and
encapsulates higher level policies. The inner most circle is the
most general.

21. Entities Entities encapsulate Enterprise wide business rules. An entity can be
an object with methods, or it can be a set of data structures and
functions. It doesn’t matter so long as the entities could be used by
many different applications in the enterprise.
If you don’t have an enterprise, and are just writing a single
application, then these entities are the business objects of the
application. They encapsulate the most general and high-level
rules.

22. Use Cases
The software in this layer contains application specific business rules.
It encapsulates and implements all of the use cases of the system.
These use cases orchestrate the flow of data to and from the
entities

23. Interface
Adapters
MVC architecture of a GUI. The Presenters, Views, and Controllers
all belong in here. The models are likely just data structures that
are passed from the controllers to the use cases, and then back
from the use cases to the presenters and views.

24. Component
Principles
If the SOLID Principles tell us how to
arrange the bricks into walls and
rooms, then the component principles
tell us how to arrange the rooms into
buildings. Large software systems, like
large buildings, are built out of
smaller components.
Component Cohesion
The Reuse/Release Equivalence Principle
The Common Closure Principle
The Common Reuse Principle
Component Coupling
The Acyclic Dependencies Principle
The Stable Dependencies Principle
The Stable Abstraction Principle

25. The Reuse/Release Equivalence Principle

26. The Common Closure Principle

27. The Common Reuse Principle

28. The Acyclic Dependencies Principle

29. The Acyclic Dependencies Principle

30. The Acyclic Dependencies Principle

31. The Acyclic Dependencies Principle

32. The Acyclic Dependencies Principle

33. The Stable Dependencies Principle

34. The Stable Dependencies Principle

35. The Stable Dependencies Principle
Fan-out = 1

36. The Stable Abstraction Principle

37. The Stable Abstraction Principle
stability
abstractness

38. Good Architecture

39. Clean Architecture
Every developer that wants to be an architect should read this
awesome book!