Why Architecture Matters

Why Architecture matters
Lars Jankowfsky, swoodoo.com

Freitag, 20. März 2009

Why Architecture matters PHPCon Italia 2009

Lars Jankowfsky

• CTO swoodoo.com
• XP, agile development fanatic
• developing since 15+ years
• php since php/ﬁ
• Software Architect > 10 years



Architecture

Zend Framework

symfony
cakePHP
ezComponents



long project lifetime




• code aging




• code aging
• big ball of mud




continuous maintenance




• strong dependency -> „co-dependency“




• deployment




• deployment
• scaling




Blaine Cook, Twitter's lead architect:
„For us, it’s really about scaling horizontally - to that end, Rails and Ruby
haven’t been stumbling blocks, compared to any other language or framework.
The performance boosts associated with a “faster” language would give us a
10-20% improvement, but thanks to architectural changes that Ruby and
Rails happily accommodated, Twitter is 10000% faster than it was in
January.“



Success



Success
• D.R.Y. == Do Not Repeat Yourself




Success
• Single responsibility principle




Single responsibility principle




• quot;if it generates XML then it should not generate HTMLquot;




• quot;if it generates XML then it should not generate HTMLquot;
• quot;if you want to serialize to xml do not create quot;toxmlquot;
Method, instead pass $this to the XMLExporterquot;




Success
• Single responsibility principle
• K.I.S.S.




K.I.S.S.




K.I.S.S.
• think in advance but don‘t think too complex




K.I.S.S.
• before making any generalisation have at least two cases




K.I.S.S.
• before making any generalisation have at least two cases
• the more abstractions the easier you can change it later



Developing

Evolution



Evolving Architecture




• Y.A.G.N.I. == You Ain‘t Gonna Need it




• Y.A.G.N.I. == You Ain‘t Gonna Need it
• Without refactoring there is no evolution



Principle of
„bad smell“


Bad smells?




Bad smells?
• Do maintenance cost keep increasing?




Bad smells?
• Simple features need too long to be implemented




Bad smells?
• Simple features need too long to be implemented
• Small changes ripple through your system



dead code


dead code
data classes


comments „what not why“

dead code
data classes


comments „what not why“

long methods
dead code
data classes



Bad Smells
• http://martinfowler.com/bliki/CodeSmell.html
• http://www.codinghorror.com/blog/archives/000589.html



Separation



Layered Architecture




• separation of concerns




• If they can live without each other - why to couple them?




• Find the boundaries and cut mercilessly.




• Do not bypass any layer!




• Do not bypass any layer!
• Separate modules/classes or go SOA




SOA




SOA
• Pro: makes scaling very easy




SOA
• Pro: clear deﬁned boundaries, no violations possible




SOA
• Pro: perfect for refactoring




SOA
• Pro: Deployment beneﬁts




SOA
• Pro: Deployment beneﬁts
• Con: integration testing gets more difﬁcult



Database


ZendDb

PDO
ADOdb
propel



Database




Database
• you need a database access layer




Database
• go ORM if possible (performance!)




Database
• Active Record has business logic




Database
• Active Record has business logic
• business layer - not abstraction layer



Db Abstraction Layer PDO, ADOdb, ZendDb....



Object Layer Table Data Gateway Pattern




Active Record
Business Layer




Active Record
Business Layer function giveMeMyData()



Controller




Controller
• Common mistake: business logic in controller




Controller
• Keep it out! Otherwise you will end with SQL in controller




Controller
• I/O mapping to the model and view only




Controller
• I/O mapping to the model and view only
• Kick Ass!




View




View
• Use a template engine. Watch performance!




View
• No business logic in the template/html




View
• No business logic in the template/html
• Kick Ass!




TDD
• enforces layered Architecture




TDD
• enforces layered Architecture
• use continuous integration (e.g. cruise control)



Unit Tests



Unit Tests
• test a single class




Unit Tests
• do not touch:




Unit Tests
• do not touch:
- database




Unit Tests
• do not touch:
- database
- network




Unit Tests
• do not touch:
- database
- network
- (ﬁles)




Unit Tests
• do not touch:
- database
- network
- (ﬁles)
• use mocks/stubs




Unit Tests
• do not touch:
- database
- network
- (ﬁles)
• use mocks/stubs
• provide fast feedback



Integration Tests

Unit Tests



Integration Tests




Integration Tests
• test several classes




Integration Tests
• test communication between classes/modules




Integration Tests
• test communication between classes/modules
• they test full components



Acceptance Tests

Integration Tests

Unit Tests



Acceptance Tests




Acceptance Tests
• test functionality from „outside“




Acceptance Tests
• often build from „user stories“




Acceptance Tests
• often build from „user stories“
• usually done with Selenium



what if fixture/mock preparation
are much larger than tests?


what if your tests run for hours ?


framework !== software architecture


evolve your architecture


split your application into layers


enforce proper usage of MVC


wrap database access


utilize test driven development



Thank you for your interest!

http://joind.in/talk/view/232



Why Architecture Matters

Recommended

Recommended

More Related Content

Similar to Why Architecture Matters

Similar to Why Architecture Matters (20)

More from Lars Jankowfsky

More from Lars Jankowfsky (9)

Recently uploaded

Recently uploaded (20)

Why Architecture Matters