Modular Architectures: What they are why do they matter now.

  • Published on

  • View

  • Download

Embed Size (px)


Software systems evolve over time. Most of them through, are quick and small ones - hacks. These changes, over a period of time makes the code spaghetti, difficult to understand, gathers tremendous Technical Debt and along they way looses the design principles by which they are designed in the first place. Fixing these problems will be risky, tedious and expensive and definitely not without the support of a proven framework.This is the first problem. There is another force that will require significant changes to existing software systems. This force is created by the changing landscape of expectations due to technologies such as cloud, big-data and REST as well as emotional experience across all touch points, not just on PCs. This is the second problem. Modular architecture addresses both these problems. It is not a novel thought or an isolated architectural style, but a structured way to refactor, rather restructure the code to make the systems easier to understand, extend and adopt to the new paradigms. The focus of Modular Architecture is the structural and physical design.


<ul><li> 1. MODULAR ARCHITECTURES By Param Rengaiah (@its_param) March 18, 2014 What they are and why do they matter now. </li> <li> 2. PROLOGUE History matters, at least to me. </li> <li> 3. This is a three part story. </li> <li> 4. PART I Definition, Sort of. </li> <li> 5. What is Software Architecture? </li> <li> 6. The word software architecture intuitively denotes the high level structures of a software system. - Wikipedia </li> <li> 7. 1 STRUCTURE OF THE SYSTEM </li> <li> 8. 2 PROCESS OF CREATING SUCH STRUCTURES </li> <li> 9. 3 RECORD OF THIS STRUCTURE </li> <li> 10. STYLES Architecture are indicated in terms of their </li> <li> 11. MANY STYLES An useful system always uses </li> <li> 12. LAYERED STYLE 1 </li> <li> 13. PHYSICAL LAYOUT Focuses on </li> <li> 14. SERVICE ORIENTED STYLE 2 </li> <li> 15. INTEGRATION &amp; CUMMINICATION Focuses on </li> <li> 16. What is Modular Architecture? </li> <li> 17. GOING ONE STEP FURTHER Modular Architecture is </li> <li> 18. SMALLER MODULES Dividing a layer or a service into </li> <li> 19. deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers. - Kirk Knoernschild MODULE IS A </li> <li> 20. CHARACTERISTICS Of a module are </li> <li> 21. 1 PHYSICAL SHOULD BE </li> <li> 22. 2 SCOPE CLEAR BUSINESS </li> <li> 23. 3 LAYERS CONFINES WITHIN EXISTING </li> <li> 24. 4 CONTEXT WORKS WITHIN ITS </li> <li> 25. 5 RATE OF CHANGE SCOPED BY </li> <li> 26. 6 INTERFACE EXPRESSED THROUGH PUBLIC </li> <li> 27. 7 STATELESS MODULE INTERFACES ARE </li> <li> 28. JAR A module in Java can be expressed as </li> <li> 29. COMPOSITION &amp; COMPREHENSION Focuses on </li> <li> 30. BENEFITS Of Modular Architectures </li> <li> 31. 1 UNDERSTAND HELP US </li> <li> 32. 2 EXTENDING MAKES IT EASY FOR </li> <li> 33. 3 DEPENDENCY HELP US MANAGE </li> <li> 34. Enabling us to </li> <li> 35. ARCHITECT ALL THE WAY DOWN </li> <li> 36. Provide us with </li> <li> 37. DESIGN TIME MODULARITY </li> <li> 38. RUNTIME MODULARITY </li> <li> 39. But my system is already modular. </li> <li> 40. FRAMEWORK DOES NOT MAKE CODE MODULAR </li> <li> 41. A NEW LANG DOES NOT MAKE CODE MODULAR </li> <li> 42. SOA DOES NOT MAKE CODE MODULAR </li> <li> 43. PRETTY DIAGRAM DOES NOT MAKE CODE EASY TO UNDERSTAND </li> <li> 44. PHYSICAL DESIGN IS THE ONLY THING THAT HELP YOU UNDERSTAND, EXTEND AND MANAGE. </li> <li> 45. PART II Prerequisites, Sort of. </li> <li> 46. But why would we want to restructure in the first place? </li> <li> 47. VISION ARCHITECTS </li> <li> 48. RESULT IS? </li> <li> 49. REALITY IS After a year or so, </li> <li> 50. SPAGHETTI Complicated, difficult to understand, and impossible to maintain is </li> <li> 51. BRIAN FOOTE JOSEPH YODER [ Big ball of mud / spaghetti ] systems show unmistakable signs of unregulated growth and repeated, expedient repair. </li> <li> 52. DESIGN ROT Tightly coupled code with excessive dependencies is known as </li> <li> 53. ROBERT C. MARTIN (UNCLE BOB) There are four primary symptoms that tell us that our designs are rotting : rigidity, fragility, immobility, and viscosity. </li> <li> 54. TECHNICAL DEBT When you choose to defer internal things that will impede future development, you incur </li> <li> 55. MARTIN FOWLER Development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments. </li> <li> 56. Restructuring addresses </li> <li> 57. 1 LOGICAL DESIGN FLAWS </li> <li> 58. MARTIN FOWLER I see refactoring as a very specific technique to do the more general activity of restructuring. Restructuring is any rearrangement of parts of a whole. </li> <li> 59. The physical architecture is the skeleton of the system if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. JOHN LAKOS </li> <li> 60. 2 PHYSICAL &amp; STRUCTURAL DESIGN FLAWS </li> <li> 61. Restructuring to Modularity. </li> <li> 62. I was fortunate to have these </li> <li> 63. 1 MODULARITY PATTERNS A BOOK ON </li> <li> 64. 2 UI MODULE SEPERATE </li> <li> 65. GWT </li> <li> 66. 3 DOMAIN MODEL SEPERATE </li> <li> 67. Ubiquitous Language </li> <li> 68. 4 EXTERNAL INTEGRATION ISOLATED </li> <li> 69. Clear business context. Explicit boundary. Physical adapters. </li> <li> 70. 5 RULES &amp; WORKFLOW GROOVY BASED </li> <li> 71. Essential Complexity Vs Accidental Complexity Choice between </li> <li> 72. 6 DESIGN &amp; ARCH REVIEWS PERIODIC </li> <li> 73. Making choices under given context and constraints. Architecture is about </li> <li> 74. 7 TRUST &amp; FAITH STAKEHOLDERS SHOULD HAVE </li> <li> 75. Trusting is one thing, but keeping you on the toe is another. </li> <li> 76. 8 IMPL TEAM ROCK STAR </li> <li> 77. Willing to unlearn what you have known for years. </li> <li> 78. PART III The works, if you say so. </li> <li> 79. 16 to 82 Number of JAR modules </li> <li> 80. How did we do it? </li> <li> 81. Arrive at a Ubiquitous Language for the domain model. </li> <li> 82. Simply the lifecycle of managed resources. </li> <li> 83. Catalog the lifecycle events, triggers, contexts and swim-lanes. </li> <li> 84. Refactor the domain model to confer to the new ubiquitous language. </li> <li> 85. Extract core domain model and reference models as separate modules. </li> <li> 86. Create a separate module to manage each stage of lifecycle for each resource. </li> <li> 87. Divide the modules further consider rate of change, rate of reuse and for removing cyclical dependencies. </li> <li> 88. Create a contract module for each external system as it relates to your business </li> <li> 89. For each of above logical modules, create two physical modules - a spec and an implementation. </li> <li> 90. Manage physical dependencies through spec modules. </li> <li> 91. Create deployable modules as a composition of smaller modules (WAR). </li> <li> 92. Deployed module endpoints are exposed as stateless REST APIs. </li> <li> 93. Composition provides runtime inter-module integrations. </li> <li> 94. Composition essentially addresses time and space. </li> <li> 95. Scalability is baked into composition. </li> <li> 96. You will arrive at an event-driven, message-driven, comprehensible, extensible, scalable and maintainable system. </li> <li> 97. EPILOGUE Why does it matter now? Finally. </li> <li> 98. Have you been asked to do any of this? </li> <li> 99. LETS ADD A MOBILE SKIN </li> <li> 100. WE SHOULD SUPPORT TOUCH DEVICES </li> <li> 101. PUT IT ON THE CLOUD </li> <li> 102. 100% SOA </li> <li> 103. ITS A SAAS APP BABY! </li> <li> 104. WE SUPPORT BIG DATA </li> <li> 105. WE DID RESPONSIVE WEB DESIGN </li> <li> 106. Modular Architecture prepares you for the future. </li> <li> 107. Talking about new trends.. </li> <li> 108. REACTIVE ARCHITECTURE </li> <li> 109. Modular Architecture is an essential facet of RESPONSIVE ARCHITECTURE. </li> <li> 110. Thank You. Follow me at @its_param </li> </ul>


View more >