1. TAMING COUPLING & COHESIVE
BEASTS WITH
MODULARITY PATTERNS
By Param Rengaiah (@its_param)

4. Creating enterprise software system is
incredibly
HARD

5. Keeping it useful and relevant is
10x HARDER

6. Cost percentage for maintenance is
70%

7. Accept and anticipate
CHANGE

8. Change is not only desirable but
ESSENTIAL

9. Spring framework growth from 14k loc in
2004 to 2013 is
1.3 MILLION

10. Changing and enhancing an application is
challenging.
WHY?

11. ARCHITECTS
VISION

13. After a year or so,
REALITY IS

18. Complicated, difficult to understand,
and impossible to maintain is
SPAGHETTI

19. BRIAN FOOTE
“
JOSEPH YODER
[ Big ball of mud / spaghetti ] systems
show unmistakable signs of unregulated
growth and repeated, expedient repair.

20. Tightly coupled code with excessive
dependencies is known as
DESIGN ROT

21. ROBERT C. MARTIN (UNCLE BOB)
“
There are four primary symptoms that
tell us that our designs are rotting :
rigidity, fragility, immobility, and
viscosity.

22. When you choose to defer internal things
that will impede future development, you
incur
TECHNICAL
DEBT

23. “
Development
organizations let their
debt get out of control
and spend most of their
future development effort
paying crippling interest
payments.
MARTIN FOWLER

24. If we know all these things, why does it
still happen?
WHY?

25. Lets take the
MASK OFF

26. 1
LOGICAL
DESIGN FLAWS

27. “
There are only two hard
things in Computer Science:
cache invalidation and
naming things.
PHIL KARLTON

32. 2
PHYSICAL
& STRUCTURAL DESIGN FLAWS

33. “ 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

34. “ 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

35. THIS IS WHERE
THE
BEAST
LIVES!

36. ARCHITECTS
VISION

38. REALITY IS?

40. HOW DO WE KNOW IF WE HAVE TAMED THE BEAST?

41. 1
CONFIDENCE
WHILE EMBRACING CHANGE

42. 2
PIVOT DESIGN
WITH LEAST CASCADING DISRUPTION

43. 3
UNDERSTAND
THE BUSINESS THROUGH CODE

44. MAINTAINING
STATUS QUO IS
NOT AN OPTION

45. Introducing
LEHMAN’S
LAW

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

47. Should we
REFACTOR?

48. “
Refactoring is a
disciplined technique for
restructuring an existing
body of code, altering its
internal structure without
changing its external
behavior.
MARTIN FOWLER

49. “ 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

53. Should we
REDESIGN?

54. Apply oop design principles like
S.O.L.I.D?

56. Tightly coupled code with excessive
dependencies is known as
DESIGN ROT

57. “ 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

58. Consider
RESTRUCTURING
TO MODULARITY

59. “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

60. What is a
MODULE?

61. “ 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

62. MANAGE
RELATIONSHIPS

63. MODULE
REUSE

64. COHESIVE
MODULES

65. ACYCLIC
RELATIONSHIPS

66. LEVELIZE
MODULES

67. PHYSICAL
LAYERS

68. CONTAINER
INDEPENDENCE

69. INDEPENDENT
DEPLOYMENT

70. PUBLISHED
INTERFACE

71. EXTERNAL
CONFIGURATION

72. DEFAULT
IMPLEMENTATION

73. MODULE
FAÇADE

74. ABSTRACT
MODULES

75. IMPLEMENTATION
FACTORY

76. SEPARATE
ABSTRACTIONS

77. UTILITY
PATTERNS

78. You need the right
TOOLS

79. Spring Tool Suite
TOOLS
App Server
Hibernate, Spring,
Spring Boots,
Groovy

88. Its time for a short demo.
YAY!

89. What about
OSGi?

91. WITH WHAT WE HAVE SEEN SO FAR,
WHAT CAN
WE INFER?

92. 1.
EXPOSE
SEAMS OF
THE SYSTEM

93. Seams?

94. 2.
ARCHITECT
ALL THE
WAY DOWN

96. I WANT TO PREVENT OR FIX MY PROJECT
WHAT CAN
I DO NOW?

97. 1
RECORD
Design debts, hacks and quick
wins

98. 2
REVIEW
The inventory at least every
six months

99. 3
REFACTOR
Logical flaws as part of regular
release cycles

100. 4
PILOT
The restructure for an isolated
feature

101. 5
PLAN
A separate release for
restructuring

102. 6
CAMPAIGN
And get the buy-in from
stakeholders

103. 7
RESTRUCTURE
The system to modularity

104. If nothing is working, there’s always …

105. THANK YOU
@its_param

106. REFERENCES AND ACKNOWLEDGEMENTS
http://www.adam-bien.com/roller/abien/entry/how_to_kill_an_osgi#comments
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