clean architecture
robert c martin talk
business rules in application : : :
aplication specific
aplication agnostic - that can be reused in several aplications - reusable code
components of an app
interactor - sort of orchestrator
entity (domain object)
boundaries - interface
click to edit
clean architecture pluralsight
mathew renze
⭐
purpose
focus
enterprise applications in agile way
architecture design, principles and practices
top 7 ideas of architecture parctice
why doesn't the high level structure of the app not tell me what it does (eg. folder names: controllers, models, API)
what is architecture
it's a high level view of software, it focuses on structure (how things are organized) , layers (vertical partitions), components (horizontal partitions), relationships how everything is wired together
levels of architecture abstraction
system, sub-system, layers, components, classes, data
what is bad architecture? ⛔
complex by mistake
rigid
brittle - you touch one part and breaks in another area
hard to test
unmaintainable
what is good architecture? ❎
simple - only as complex as necessary, and by design not by accident
understandable - easy to reason about, intuitive
flexible
emergent - evolves along with the needs of the application
testable
maintanable
clean architecture
design for the inhabitants ( developers and users); avoid premature optimization
why invest in clean architecture
minimize de cost of developing software and maximize usefullnes, increase return on investment
focus on the essential - implement what is necessary when it's necessary; optimize maintenance
click to edit
all decisions are tradeofss : ❤
architecture types 💥
domain centric architecture
essential in solving a domain problem
domain, use cases
details: presentation, persistance
samples
no inner layer knows of the outer layer, it's testable without UI or server
benefits
focus on the domain - which is essential in solving the use domain pb
less coupling between domain and implementation details ( presentation, persistance)
allows to incorporate domain driven design
downsides
more tought to decide what goes into domain and what goes application layer;
initial cost is higher but pays off if the app has a long lifecycle
layered architecture
modern version - use dependency inversion
pros
- focus on the use cases
- easy to understand
- dep inversion
- expensive to add layaers?
cons
- decision on what belongs where
- inversion of control is counterintuitive
CQRS - commands and queries
in real live scenarios is hard to separate commands and queries - e.g. insert a new item - should return the ID
increases code cleanes
single DB CQRS
two DB CQRS
- the write and read DB should be synced in a matter of miliseconds
event sourcing - most complex version of CQRS
- save operations/transactions in one db, replay the events in order to get the final version of a data
- keep a DB where the final version of the data is computed so read access is fast
- it's easy to debug, replay events, can have multiple read databases, can reconstruct events at any point in time
- perfect for audit and traceability
pros
- easy to use for domain driver design
- better performance
- efficient design
- on queries you can bypass domain model to retrieve the data specific for the UI -> this can result in a more performant system
cons
- inconsistency
- more complex
functional organization
screaming architecture - promotes visibility of the use cases of the app
categorical vs functional cohesion
organize by components(categorical) or use cases (functional)
functional cohesion is more logical
use spatial locality - things that are used together are placed together - it promotes better separation
cons
- loose framework conventions
- categorical is easier at first
microservices
smaller teams but need good communication and coordination between teams
good explanation of domain driven design - even if we have a similar entity in a domain, it could be smart to separate into several entities based on the bounded context
how big should a microservice be and where should the boundary be? - use bounded contexts
allows each team to focus on the single domain knowledge
high cohesion, low coupling
microservices allows flexibility in technical decisions ( services can have different architectures)
pros
- less costly to build a microservice than a whole app - in a long app lifecycle, in theory can reduce cost
- cohesion/cupling of application, domain knowledge , DBs
- independence
cons
- high cost at the beginning, better suited for large projects instead of smaller ones
- needs communication
- distributed communication - latency over network
testing
test categories:
what is being tested
why they are tested
how is the test made
evolving the architecture
- due to requirements change, market change
- delay decisions as much as possible
- implement simplest and useful use cases first