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

663 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
663
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

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

×