Embed Size (px)
DESCRIPTION
Most dev teams have a very simple conception of software architecture. They start with a database, a user interface, and add layers of (DRY) mess between the two. Then they have a performance problem so they add memcache and mongodb (Now we're webscale!). Months or years later, releasing new features in production gets harder and riskier: it's time for a rewrite. Let's use AnguNodeMvcDoop to solve all our maintainability issues! And the cycle starts over... In this talk we'll see that software architecture is not defined by the technologies you use but by the high level principles you set. We'll see what really matters to make your information system maintainable and how to get there progressively!
Citation preview
Refactor your Software Architecture
Who am I?Julien Lavigne du CadetDev lead at Criteo
http://fr.linkedin.com/in/julienlavigneducadet/@julienlavigne
How to structure yourenterprise applications
… a business problem!
We often start with…
That we try to solve with…
That we try to solve with…
Languages
Frameworks
Persistencetechnologies
...and a 3 tiers architecture
Business
Data
UI
…and a 3 tiers architecture
Asp.net MVC
SQL Server
Angular
…and a 3 tiers architecture
WCF
SQL Server
WPF
...and a 3 tiers architecture
Play
Oracle
Ember
With some layers…
DTOApplication LogicBusiness LogicData Access
Database
UI
With some layers…
Application LogicBusiness LogicData Access
Database
UI
And it grows…
And it grows…
… and it gets slow!
And it gets unmaintanable!
Why?Why?
Releases are all or nothing*
Releases are all or nothing**Some people will tell you that’s why we have stored procedures... Don’t trust them :p.
Refactorings are expansiveMigrating to new frameworks requires rewriting a whole layer
One size doesn’t fit allHard to have custom solutions for a vertical
What can we do?
We learned to split in the wrong direction
Split the system into small components…
… releasable independently from each other
Architecture:interfaces and interactions between our components
Business
Database
UI
Or how to go from…
UI
To…
UI
Or more realistically to…
Business
Database
UI
Or even that…
Business
Database
Job Scheduler
How do we proceed?
Start small
Identify one featurethat has few dependencies… Example: sending emails
Define the APIinterface & communication protocol
Choose an architectural style
RESTWEB SERVICESERVICE BUS…
What is the offered service?
What is the offered service?
InputsFROMTOTITLEBODY
What is the offered service?
InputsFROMTOTITLEBODY
OutputsACK / ERROR CODECALLBACKS / EVENTS
UI
Focus on
Implement and deploydeployment should be independent of everything else!
Replace usages everywhere
Go back to step one and… start again**a lot… :-)
The next steps
Start writing all new code in components
Encapsulate legacy codeIt’s fine to have some uglyness in a component as long as the interface is clean!
Define clear boundaries
Make everything accessible through an APIFrom business features to technical features
What did we achieve?
Reuse and centralisation
Independent deployments…and rollbacks!Shorter release cycles, less risks, happy users!
Independent component designsKeep It Simple, Stupid
Independent component designsExperiment!
Replaceable components
Easier testingTest the component & the interactions with the component
In conclusion…
Software architecture is aboutdefining high level principles…
To shorten release cycles…
And keep the system maintenable
My suggestion
build small components…
That communicate throuh defined interfaces
Give it a try!
Thank you!
We’re hiring!http://www.criteo.com/en/jobs
