Why Architecture in Web Development matters

7,533 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
2 Comments
5 Likes
Statistics
Notes
  • 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
No Downloads
Views
Total views
7,533
On SlideShare
0
From Embeds
0
Number of Embeds
1,907
Actions
Shares
0
Downloads
146
Comments
2
Likes
5
Embeds 0
No embeds

No notes for slide














  • strong dependency -> „co-dependency“




  • \"if you want to serialize to xml do not create \"toxml\" Method, instead pass $this to the XMLExporter\"
  • think in advance but don‘t think too complex
    before making any generalisation have at least two cases
    the more abstractions the easier you can change it later
  • nobody said it will be easy
  • tightrope walk
























  • preparing fixtures/Mocks difficult
  • preparing fixtures/Mocks difficult
  • preparing fixtures/Mocks difficult
  • preparing fixtures/Mocks difficult
  • preparing fixtures/Mocks difficult












  • do not spread db calls through your code
    one function or object generates one „business“ result
    data access object
  • do not spread db calls through your code
    one function or object generates one „business“ result
    data access object
  • do not spread db calls through your code
    one function or object generates one „business“ result
    data access object





  • lazy loading ok

    in Ruby all Variables from controller are accessable.
  • lazy loading ok

    in Ruby all Variables from controller are accessable.
  • lazy loading ok

    in Ruby all Variables from controller are accessable.
  • Do not reinvent the wheel. Use frameworks





  • at least daily
  • test a single class
    do not touch database, network, (files)
    use mocks/stubs and provide fast feedback
  • test several classes
    test communication between classes/modules
    they test full components
  • test functionality from „outside“
    often build from „user stories“
    usually done with Selenium -> not only selenium example openapi























  • 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,

    ×