TAMING COUPLING & COHESIVE BEASTS WITH
MODULARITY PATTERNS AND SPRING
By Param Rengaiah
© 2013 SpringOne 2GX. All rights r...
CREATING ENTERPRISE SOFTWARE
SYSTEM IS INCREDIBLY

HARD
KEEPING IT USEFUL AND RELEVANT IS

HERCULEAN
COST PERCENTAGE FOR MAINTENANCE
IS

70%
ACCEPT AND ANTICIPATE

CHANGE
CHANGE IS NOT ONLY DESIRABLE BUT

ESSENTIAL
SPRING FRAMEWORK GROWTH
FROM 14K LOC IN 2004 TO 2013 IS

1.3 MILLION
CHANGING AND ENHANCING AN
APPLICATION IS CHALLENGING.

WHY?
ARCHITECTS

VISION
AFTER A YEAR OR SO,

REALITY IS
COMPLICATED, DIFFICULT TO UNDERSTAND,
AND IMPOSSIBLE TO MAINTAIN IS

SPAGHETTI
BRIAN FOOTE

“

JOSEPH YODER

[ Big ball of mud / spaghetti ] systems
show unmistakable signs of unregulated
growth and re...
TIGHTLY COUPLED CODE WITH
EXCESSIVE DEPENDENCIES IS KNOWN AS

DESIGN ROT
ROBERT C. MARTIN (UNCLE BOB)

“

There are four primary symptoms that
tell us that our designs are rotting :
rigidity, fra...
WHEN YOU CHOOSE TO DEFER
INTERNAL THINGS THAT WILL IMPEDE
FUTURE DEVELOPMENT, YOU INCUR

TECHNICAL
DEBT
“
Development
organizations let their
debt get out of control
and spend most of their
future development effort
paying cri...
IF WE KNOW ALL THESE THINGS, WHY
DOES IT STILL HAPPEN?

WHY?
LETS TAKE THE

MASK OFF
1

LOGICAL
DESIGN FLAWS
“
There are only two hard
things in Computer Science:
cache invalidation and
naming things.

PHIL KARLTON
2

PHYSICAL
& STRUCTURAL DESIGN FLAWS
“ physical architecture
The
is the skeleton of the
system – if it is
malformed, there is no
cosmetic remedy for
alleviatin...
“ quality of the
The
physical design of a large
system will dictate the
cost of its maintenance
and the potential it has
f...
THIS IS WHERE

THE
BEAST
LIVES!
REALITY IS?
HOW DO WE KNOW WE HAVE TAMED
THE BEAST?
1

CONFIDENCE
WHILE EMBRACING CHANGE
2

PIVOT DESIGN
WITH LEAST CASCADING DISRUPTION
3

UNDERSTAND
THE BUSINESS THROUGH CODE
INTRODUCING

LEHMAN’S
LAW
“ a system evolves, its
As
complexity increases
unless work is done to
maintain or reduce it.
- LEHMAN’S SECOND LAW

MANNY...
SHOULD WE

REFACTOR?
“
Refactoring is a
disciplined technique for
restructuring an existing
body of code, altering its
internal structure witho...
“ heart is a series of small
Its
behavior preserving
transformations.
Each transformation does
little, but a sequence such...
APPLY OOP DESIGN PRINCIPLES LIKE

S.O.L.I.D?
TIGHTLY COUPLED CODE WITH
EXCESSIVE DEPENDENCIES IS KNOWN AS

DESIGN ROT
“ physical architecture
The
is the skeleton of the
system – if it is
malformed, there is no
cosmetic remedy for
alleviatin...
RESTRUCTURING
TO MODULARITY
“see refactoring as a very
I
specific technique to do the
more general activity of
restructuring.
Restructuring is any
rear...
“ dancing! By God
I’m
I’m dancing on the
walls. I’m dancing on
the ceiling. I’m ecstatic.
I’m overjoyed. I’m
really, reall...
MANAGE
RELATIONSHIPS
MODULE
REUSE
COHESIVE
MODULES
ACYCLIC
RELATIONSHIPS
LEVELIZE
MODULES
PHYSICAL
LAYERS
CONTAINER
INDEPENDENCE
INDEPENDENT
DEPLOYMENT
PUBLISHED
INTERFACE
EXTERNAL
CONFIGURATION
DEFAULT
IMPLEMENTATION
MODULE
FAÇADE
ABSTRACT
MODULES
IMPLEMENTATION
FACTORY
SEPARATE
ABSTRACTIONS
UTILITY
PATTERNS
YOU NEED THE RIGHT

TOOLS
Spring Tool Suite

TOOLS

App Server

Hibernate, Spring,
Spring Boots, Groovy
ITS TIME FOR A SHORT DEMO.

YAY!
SO, WHAT CAN
WE INFER?
1.

EXPOSE
SEAMS OF
THE SYSTEM
2.

ARCHITECT
ALL THE
WAY DOWN
I CAN’T START THE RESTRUCTURE TODAY.

WHAT
NOW?
1

RECORD
DESIGN DEBTS, HACKS AND
QUICK WINS
2

REVIEW
THE INVENTORY AT LEAST
EVERY SIX MONTHS
3

REFACTOR
LOGICAL FLAWS AS PART OF
REGULAR RELEASE CYCLES
4

PILOT
THE RESTRUCTURE FOR AN
ISOLATED FUNCTION
5

PLAN
A SEPARATE RELEASE FOR
RESTRUCTURING
6

CAMPAIGN
AND GET THE BUY-IN FROM
STAKEHOLDERS
7

RESTRUCTURE
THE SYSTEM TO MODULARITY
THANK YOU
@its_param
REFERENCES AND ACKNOWLEDGEMENTS
http://baruzzo.wordpress.com/2009/07/01/physical-design-vs-logical-design-part-i/
http://b...
Learn More. Stay Connected.

https://medium.com/@its_param
https://medium.com/on-software-architecture/46603626bc1e
Twitte...
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring
Upcoming SlideShare
Loading in...5
×

Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring

2,232

Published on

Speaker: Param Rengaiah
By now you should have heard about coupling and cohesiveness. These concepts, and their third cousin, polymorphism, is what we as developers chase day-in and day-out. They tease us with reusability and the promise of comprehensiveness of our code. They entice us with promises of code quality and testability. They came in the form of "Object Oriented' design, followed by GoF and SOLID Design Patterns, DDD, BDD.. but none of them delivered what they promised. Now, the new kids on the block are Functional Programming and Modularity Patterns.
What happens when you choose to go through large refactoring exercise on the back of Modularity Patterns, in a large, complex enterprise project? The journey was long, arduous and gruesome. On the way, I made many enemies and found some new friends. This talk will highlight the issues, both technical and otherwise, and how it was overcome; where did Spring help and where did it hurt. In the end, was it worth it? Come to this session and you will find out.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,232
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Taming Coupling & Cohesive Beasts with Modularity Patterns and Spring

  1. 1. TAMING COUPLING & COHESIVE BEASTS WITH MODULARITY PATTERNS AND SPRING By Param Rengaiah © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
  2. 2. CREATING ENTERPRISE SOFTWARE SYSTEM IS INCREDIBLY HARD
  3. 3. KEEPING IT USEFUL AND RELEVANT IS HERCULEAN
  4. 4. COST PERCENTAGE FOR MAINTENANCE IS 70%
  5. 5. ACCEPT AND ANTICIPATE CHANGE
  6. 6. CHANGE IS NOT ONLY DESIRABLE BUT ESSENTIAL
  7. 7. SPRING FRAMEWORK GROWTH FROM 14K LOC IN 2004 TO 2013 IS 1.3 MILLION
  8. 8. CHANGING AND ENHANCING AN APPLICATION IS CHALLENGING. WHY?
  9. 9. ARCHITECTS VISION
  10. 10. AFTER A YEAR OR SO, REALITY IS
  11. 11. COMPLICATED, DIFFICULT TO UNDERSTAND, AND IMPOSSIBLE TO MAINTAIN IS SPAGHETTI
  12. 12. BRIAN FOOTE “ JOSEPH YODER [ Big ball of mud / spaghetti ] systems show unmistakable signs of unregulated growth and repeated, expedient repair.
  13. 13. TIGHTLY COUPLED CODE WITH EXCESSIVE DEPENDENCIES IS KNOWN AS DESIGN ROT
  14. 14. ROBERT C. MARTIN (UNCLE BOB) “ There are four primary symptoms that tell us that our designs are rotting : rigidity, fragility, immobility, and viscosity.
  15. 15. WHEN YOU CHOOSE TO DEFER INTERNAL THINGS THAT WILL IMPEDE FUTURE DEVELOPMENT, YOU INCUR TECHNICAL DEBT
  16. 16. “ Development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments. MARTIN FOWLER
  17. 17. IF WE KNOW ALL THESE THINGS, WHY DOES IT STILL HAPPEN? WHY?
  18. 18. LETS TAKE THE MASK OFF
  19. 19. 1 LOGICAL DESIGN FLAWS
  20. 20. “ There are only two hard things in Computer Science: cache invalidation and naming things. PHIL KARLTON
  21. 21. 2 PHYSICAL & STRUCTURAL DESIGN FLAWS
  22. 22. “ physical architecture The is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. JOHN LAKOS
  23. 23. “ quality of the The physical design of a large system will dictate the cost of its maintenance and the potential it has for the independent reuse of its subsystems. JOHN LAKOS
  24. 24. THIS IS WHERE THE BEAST LIVES!
  25. 25. REALITY IS?
  26. 26. HOW DO WE KNOW WE HAVE TAMED THE BEAST?
  27. 27. 1 CONFIDENCE WHILE EMBRACING CHANGE
  28. 28. 2 PIVOT DESIGN WITH LEAST CASCADING DISRUPTION
  29. 29. 3 UNDERSTAND THE BUSINESS THROUGH CODE
  30. 30. INTRODUCING LEHMAN’S LAW
  31. 31. “ a system evolves, its As complexity increases unless work is done to maintain or reduce it. - LEHMAN’S SECOND LAW MANNY LEHMAN
  32. 32. SHOULD WE REFACTOR?
  33. 33. “ Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. MARTIN FOWLER
  34. 34. “ heart is a series of small Its behavior preserving transformations. Each transformation does little, but a sequence such transformations can produce a significant restructuring. MARTIN FOWLER
  35. 35. APPLY OOP DESIGN PRINCIPLES LIKE S.O.L.I.D?
  36. 36. TIGHTLY COUPLED CODE WITH EXCESSIVE DEPENDENCIES IS KNOWN AS DESIGN ROT
  37. 37. “ physical architecture The is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. JOHN LAKOS
  38. 38. RESTRUCTURING TO MODULARITY
  39. 39. “see refactoring as a very I specific technique to do the more general activity of restructuring. Restructuring is any rearrangement of parts of a whole. MARTIN FOWLER
  40. 40. “ dancing! By God I’m I’m dancing on the walls. I’m dancing on the ceiling. I’m ecstatic. I’m overjoyed. I’m really, really pleased. FROM THE FOREWORD BY ROBERT C. MARTIN
  41. 41. MANAGE RELATIONSHIPS
  42. 42. MODULE REUSE
  43. 43. COHESIVE MODULES
  44. 44. ACYCLIC RELATIONSHIPS
  45. 45. LEVELIZE MODULES
  46. 46. PHYSICAL LAYERS
  47. 47. CONTAINER INDEPENDENCE
  48. 48. INDEPENDENT DEPLOYMENT
  49. 49. PUBLISHED INTERFACE
  50. 50. EXTERNAL CONFIGURATION
  51. 51. DEFAULT IMPLEMENTATION
  52. 52. MODULE FAÇADE
  53. 53. ABSTRACT MODULES
  54. 54. IMPLEMENTATION FACTORY
  55. 55. SEPARATE ABSTRACTIONS
  56. 56. UTILITY PATTERNS
  57. 57. YOU NEED THE RIGHT TOOLS
  58. 58. Spring Tool Suite TOOLS App Server Hibernate, Spring, Spring Boots, Groovy
  59. 59. ITS TIME FOR A SHORT DEMO. YAY!
  60. 60. SO, WHAT CAN WE INFER?
  61. 61. 1. EXPOSE SEAMS OF THE SYSTEM
  62. 62. 2. ARCHITECT ALL THE WAY DOWN
  63. 63. I CAN’T START THE RESTRUCTURE TODAY. WHAT NOW?
  64. 64. 1 RECORD DESIGN DEBTS, HACKS AND QUICK WINS
  65. 65. 2 REVIEW THE INVENTORY AT LEAST EVERY SIX MONTHS
  66. 66. 3 REFACTOR LOGICAL FLAWS AS PART OF REGULAR RELEASE CYCLES
  67. 67. 4 PILOT THE RESTRUCTURE FOR AN ISOLATED FUNCTION
  68. 68. 5 PLAN A SEPARATE RELEASE FOR RESTRUCTURING
  69. 69. 6 CAMPAIGN AND GET THE BUY-IN FROM STAKEHOLDERS
  70. 70. 7 RESTRUCTURE THE SYSTEM TO MODULARITY
  71. 71. THANK YOU @its_param
  72. 72. REFERENCES AND ACKNOWLEDGEMENTS http://baruzzo.wordpress.com/2009/07/01/physical-design-vs-logical-design-part-i/ http://blogs.msdn.com/b/ericlippert/archive/2009/04/06/good-names.aspx http://docs.oracle.com/javaee/6/tutorial/doc/bnadx.html http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution http://en.wikipedia.org/wiki/Technical_debt http://interactiveasp.net/blogs/softwarepsychology/archive/2009/12/23/the-blame-game.aspx http://martinfowler.com/bliki/RefactoringMalapropism.html http://martinfowler.com/bliki/TechnicalDebt.html http://martinfowler.com/bliki/TechnicalDebt.html http://martinfowler.com/books/refactoring.html http://mikadomethod.wordpress.com/2009/12/09/introduction-to-the-mikado-method/#more-1 http://stackoverflow.com/questions/1030388/how-to-overcome-the-anti-pattern-big-ball-of-mud http://upload.wikimedia.org/wikipedia/commons/7/7b/Hammer2.jpg http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-disasters.html http://www.construx.com/10x_Software_Development/Technical_Debt/ http://www.flickr.com/photos/tambako/494118044/ http://www.informit.com/authors/bio.aspx?a=410e6d20-a168-41cb-8d5e-93b14e4843d9 http://www.jsjf.demon.co.uk/thesis/Thesis.html http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/ http://www.kirkk.com/modularity/pattern-catalog/ http://www.laputan.org/mud/ http://www.ohloh.net/p/spring/analyses/latest/languages_summary
  73. 73. Learn More. Stay Connected. https://medium.com/@its_param https://medium.com/on-software-architecture/46603626bc1e Twitter: twitter.com/springsource YouTube: youtube.com/user/SpringSourceDev Google +: plus.google.com/+springframework LinkedIn: springsource.org/linkedin Facebook: facebook.com/groups/springsource
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×