TAMING COUPLING & COHESIVE BEASTS WITH

MODULARITY PATTERNS By Param Rengaiah (@its_param)

Creating enterprise software system is incredibly

HARD

Keeping it useful and relevant is

10x HARDER

Cost percentage for maintenance is

70%

CHANGE

Accept and anticipate

ESSENTIAL

Change is not only desirable but

Spring framework growth from 14k loc in 2004 to 2013 is

1.3 MILLION

WHY?

Changing and enhancing an application is challenging.

VISION ARCHITECTS

REALITY IS After a year or so,

SPAGHETTI

Complicated, difficult to understand, and impossible to maintain is

BRIAN FOOTE JOSEPH YODER

[ Big ball of mud / spaghetti ] systems show unmistakable signs of unregulated growth and repeated, expedient repair.

“

DESIGN ROT

Tightly coupled code with excessive dependencies is known as

ROBERT C. MARTIN (UNCLE BOB)

There are four primary symptoms that tell us that our designs are rotting : rigidity, fragility, immobility, and viscosity.

“

TECHNICAL DEBT

When you choose to defer internal things that will impede future development, you incur

MARTIN FOWLER

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

“

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

WHY?

MASK OFF

Lets take the

1 LOGICAL DESIGN FLAWS

PHIL KARLTON

There are only two hard things in Computer Science: cache invalidation and naming things.

“

2PHYSICAL & STRUCTURAL DESIGN FLAWS

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

JOHN LAKOS

The quality of 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.

“

THE BEAST LIVES!

THIS IS WHERE

VISION ARCHITECTS

REALITY IS?

HOW DO WE KNOW IF WE HAVE TAMED THE BEAST?

1 CONFIDENCE WHILE EMBRACING CHANGE

2PIVOT DESIGN WITH LEAST CASCADING DISRUPTION

3UNDERSTAND THE BUSINESS THROUGH CODE

MAINTAINING STATUS QUO IS NOT AN OPTION

LEHMAN’S LAW

Introducing

As a system evolves, its complexity increases unless work is done to maintain or reduce it.

“

MANNY LEHMAN - LEHMAN’S SECOND LAW

REFACTOR? Should we

MARTIN FOWLER

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

“

MARTIN FOWLER

Its heart is a series of small behavior preserving transformations. Each transformation does little, but a sequence such transformations can produce a significant restructuring.

“

REDESIGN? Should we

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

DESIGN ROT

Tightly coupled code with excessive dependencies is known as

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

RESTRUCTURING TO MODULARITY

Consider

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.

“

MODULE? What is a

I’m dancing! By God 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

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

TOOLS You need the right

TOOLS

Spring Tool Suite

App ServerHibernate, Spring,

Spring Boots, Groovy

YAY!

Its time for a short demo.

OSGi?

What about

WHAT CAN WE INFER?

WITH WHAT WE HAVE SEEN SO FAR,

1. EXPOSE SEAMS OF THE SYSTEM

Seams?

2. ARCHITECT ALL THE WAY DOWN

WHAT CAN I DO NOW?

I WANT TO PREVENT OR FIX MY PROJECT

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 feature

5 PLAN A separate release for restructuring

6 CAMPAIGN And get the buy-in from stakeholders

7 RESTRUCTURE The system to modularity

If nothing is working, there’s always …

THANK YOU @its_param

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

REFERENCES AND ACKNOWLEDGEMENTS