© 2013 Spring, by Pivotal

TAMING COUPLING & COHESIVE BEASTSWITH MODULARITY PATTERNS AND SPRING

Param Rengaiah, Experience Architect@its_param

22

Creating enterprise software system is incredibly HARD.

33

Keeping it useful and relevantis even more

HARDER!

http://www.flickr.com/photos/teddyllovet/9421262432/

44

70%That’s the percentage cost spent on maintaining large enterprise

applications.

55

CHANGEis not only essential but desirable

66

SPRING FRAMEWORK

LOC on March 2004 – 14 K LOC on August 2013 – 1.3 M

77

WHY?is it difficult to modify and enhance an application?

88

BACKSTORYMy personal journey and why I am passionate about this subject.

99

Possible Reasons

Development spends too much time in understanding existing implementation

Class names are too generic and hence the responsibility of a class gets wide and complex

Business rules are spread across multiple architectural layers

Too many if / else and switch / cases in classes

Direct usage of implementation classes in parent modules

1010

TECHNICAL DEBTSection 5.2 on [5], [6] and [7]

1111

“Technical Debt is a wonderful metaphor developed by Ward Cunningham… In this metaphor, doing things the quick and dirty way sets us up with a

technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs

interest payments, which come in the form of the extra effort that we have to do in future

development because of the quick and dirty design choice.

- Martin Fowler

1212

DESIGN ROTSection 5.3 on [5]

1313

“ There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal,

but are related to each other in ways that will become obvious. they are: rigidity, fragility,

immobility, and viscosity.

- Uncle Bob

1414

BIG BALL OF MUDVisit the links [2], [3] and [4]

1515

QUESTION TIMEOpen your most recent project and search for classes with *util*, *helper*

and *manager*

1616

SUFFERINGEssentially leads to

1717

SUCH AS

Forcing your team to continuously work long hours.

Burning out your best team members.

High churn rate of resources.

Create psychological divide between development, testing and operations team.

Setting up your team member to just play safe.

Basically, unpleased work environment.

At the worst - completely scrapping the project.

1818

BEAST !!!Congratulations!!! You have unleashed the

1919

TAME THE BEAST?So, how do we

2020

DREAMLets

2121

CONFIDENCEWhile embracing change

2222

PIVOTThe design with least amount of cascading disruption.

2323

UNDERSTANDThe business and the business constrains through

CODE

2424

LEHMAN’S LAWIntroducing

2525

Second Law.

As a system evolves, its complexity increases unless work is done to maintain

or reduce it.

Specifically,

“

2626

REFACTORINGTHE DESIGN

So the magic ingredient is …

2727

PHYSICAL & STRUCTURAL

DESIGN

Specifically,

2828

2929

3030

3131

3232

3333

COHESIVE MODULES

Module behavior should serve a singular purpose

3434

3535

3636

3737

3838

3939

ABSTRACT MODULES

Depend upon the abstract elements of a module.

4040

SEPARATE ABSTRACTIONS

Place abstractions and the classes that implement them in separate modules.

4141

4242

SPEC AND IMPL MODULES

Also fulfills SRP and DIP in SOLID Principles

Leads us to create

4343

IMPLEMENTATION FACTORY

Use factories to create a module’s implementation classes.

4444

SPRING AND EXTENSIONInjecting extensions in a non-intrusive way.

4545

4646

MANAGE RELATIONSHIPS

Design module relationships.

4747

ACYCLIC RELATIONSHIPS

Module relationships must be acyclic.

4848

DDD – BOUNDED CONTEXT

Anti-Corruption Layer

4949

ADAPTER ModulesAnd corresponding SPEC and IMPL modules

5050

5151

DEMO TIME

5252

SEAMS OF THE SYSTEM

Expose

5353

ALL THE WAY DOWN

Architect

5454

MODULARDesign?

Why not start with a

5555

RECORDDesign debts, hacks and quick wins

5656

REVIEWThe Inventory every six month

5757

PLANA separate release for paying the principle

5858

BUY-INFrom stakeholders

Get the

5959

REFACTORTo Modularity

6060

THANK YOU !!!Connect me on twitter at @its_param

Email me at param.rengaiah@aspiresys.com

6161

Please come.

SPRING CONFERENCE

6262

http://panelpicker.sxsw.com/vote/22263

Please share and vote!

UX DESIGN

6363

https://medium.com/@its_paramPlease visit.

MY BLOG

6464

References

1. http://www.jsjf.demon.co.uk/thesis/Thesis.html

2. http://www.laputan.org/mud/

3. http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-disasters.html

4. http://stackoverflow.com/questions/1030388/how-to-overcome-the-anti-pattern-big-ball-of-mud

5. http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/

6. http://en.wikipedia.org/wiki/Technical_debt

7. http://martinfowler.com/bliki/TechnicalDebt.html

8. http://interactiveasp.net/blogs/softwarepsychology/archive/2009/12/23/the-blame-game.aspx

6565

References

9. http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

10. http://www.kirkk.com/modularity/pattern-catalog/

11. http://www.ohloh.net/p/spring/analyses/latest/languages_summary