Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Why Architecture in Web Development matters

7,645 views

Published on

Choosing the right software architecture for your project is very important. Besides the framework decision there are many other key issues you need to take into account and which have an impact on such things like maintainability, scalability and also the frequency of possible deployments. In this session you will to learn how to avoid the common pitfalls and traps during your project.

Published in: Technology
  • Slide 14: at the time of your talk twitter had already removed ruby from the backend and substituted it with scala.
    http://www.artima.com/scalazine/articles/twitter_on_scala.html
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Download is broken, it's trying to give me a GPG key.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Why Architecture in Web Development matters

  1. 1. Why Architecture Lars matters Jankowfsky, swoodoo.com
  2. 2. Lars Jankowfsky • CTO and (Co-)Founder swoodoo AG • (Co-)Founder OXID eSales AG • XP, agile development fanatic • developing since 15+ years • php since php/fi • Software Architect > 10 years Lars Jankowfsky,
  3. 3. Architectur e
  4. 4. Zend Framework symfony cakePHP ezComponent s
  5. 5. (c) istockphoto success (c) aboutpixel.de
  6. 6. Scale!
  7. 7. Speed!
  8. 8. Deploy!
  9. 9. long project lifetime
  10. 10. (c) istockphoto code aging
  11. 11. (c) istockphoto big ball of mud
  12. 12. (c) istockphoto continuous maintenance
  13. 13. „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.“ Blaine Cook, Twitter's lead architect Lars Jankowfsky,
  14. 14. Principles of success
  15. 15. D.R.Y. Do Not Repeat Yourself
  16. 16. Single responsibility quot;if it generates XML then it should not gene principle
  17. 17. K.I.S.S. don‘t think too complex
  18. 18. (c) spackletoe http://www.flickr.com/photos/spackletoe/90811910/) (c) aboutpixel.de
  19. 19. (c) istockphoto (c) aboutpixel.de
  20. 20. Developing
  21. 21. Art
  22. 22. (c) dasbeibi @ aboutpixel.de
  23. 23. Evolving Architecture
  24. 24. Y.A.G.N.I. You Ain‘t Gonna Need it
  25. 25. No refactoring , no evolution.
  26. 26. (c) istockphoto
  27. 27. Principle of „bad smell“
  28. 28. Bad smells? Lars Jankowfsky,
  29. 29. Bad smells? • Do maintenance cost keep increasing? Lars Jankowfsky,
  30. 30. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented Lars Jankowfsky,
  31. 31. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented • Small changes ripple through your system Lars Jankowfsky,
  32. 32. dead code
  33. 33. dead code data classes
  34. 34. comments „what not why“ dead code data classes
  35. 35. comments „what not why“ long methods dead code data classes
  36. 36. • http://martinfowler.com/bliki/CodeSmell.html • http://www.codinghorror.com/blog/archives/ 000589.html Lars Jankowfsky,
  37. 37. Architecture?
  38. 38. Layered Architecture Lars Jankowfsky,
  39. 39. Layered Architecture • separation of concerns Lars Jankowfsky,
  40. 40. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? Lars Jankowfsky,
  41. 41. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. Lars Jankowfsky,
  42. 42. 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! Lars Jankowfsky,
  43. 43. 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! • Separate modules/classes or go SOA Lars Jankowfsky,
  44. 44. SOA Lars Jankowfsky,
  45. 45. SOA • Pro: makes scaling very easy Lars Jankowfsky,
  46. 46. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible Lars Jankowfsky,
  47. 47. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring Lars Jankowfsky,
  48. 48. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits Lars Jankowfsky,
  49. 49. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits • Con: integration testing gets more difficult Lars Jankowfsky,
  50. 50. (c) istockphoto Extend!
  51. 51. (c) istockphoto Scale!
  52. 52. Database
  53. 53. ZendDb ADOdb PDO doctrine propel
  54. 54. Database Lars Jankowfsky,
  55. 55. Database • you might use a database access layer Lars Jankowfsky,
  56. 56. Database • you might use a database access layer • go ORM if you want (performance!) Lars Jankowfsky,
  57. 57. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer Lars Jankowfsky,
  58. 58. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer • let‘s call it Data Access Object Lars Jankowfsky,
  59. 59. DB Abstraction Layer PDO, ADOdb, ZendDb....
  60. 60. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern
  61. 61. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer
  62. 62. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer function giveMeMyData()
  63. 63. MVC
  64. 64. Controller Lars Jankowfsky,
  65. 65. Controller • Common mistake: business logic in controller Lars Jankowfsky,
  66. 66. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller Lars Jankowfsky,
  67. 67. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only Lars Jankowfsky,
  68. 68. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only • Kick Ass! Lars Jankowfsky,
  69. 69. View Lars Jankowfsky,
  70. 70. View • Use a template engine. Watch performance! Lars Jankowfsky,
  71. 71. View • Use a template engine. Watch performance! • No business logic in the template/html Lars Jankowfsky,
  72. 72. View • Use a template engine. Watch performance! • No business logic in the template/html • Kick Ass! Lars Jankowfsky,
  73. 73. (c) istockphoto
  74. 74. TDD
  75. 75. Enforces layered Architecture
  76. 76. use continuous integration e.g. cruise con
  77. 77. Commit frequently.
  78. 78. Unit Tests
  79. 79. Integration Tests Unit Tests
  80. 80. Acceptance Tests Integration Tests Unit Tests
  81. 81. what if fixture/mock preparation are much larger than tests?
  82. 82. what if your tests run for hours ?
  83. 83. (c) istockphoto
  84. 84. framework !== software architecture
  85. 85. evolve your architecture
  86. 86. split your application into layers
  87. 87. enforce proper usage of MVC
  88. 88. wrap database access
  89. 89. utilize test driven development
  90. 90. (c) dasbeibi @ aboutpixel.de
  91. 91. lars.jankowfsky@swoodoo.com Lars Jankowfsky / Thorsten all pictures (c) iStockPhoto if not stated different
  92. 92. C M V
  93. 93. C M V
  94. 94. C M V
  95. 95. C M V
  96. 96. Project structure • Remember? Find Boundaries and cut. • quot;Services/Layersquot; - at least on a directory level • use Framework structure • more ??? Lars Jankowfsky,
  97. 97. identify important decisions
  98. 98. scaling? Lars Jankowfsky,
  99. 99. scaling? • web Lars Jankowfsky,
  100. 100. scaling? • web • database Lars Jankowfsky,
  101. 101. scaling? • web • database • services (ext./int.) Lars Jankowfsky,

×