taming coupling and cohesive beasts
DESCRIPTION
TRANSCRIPT
© 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
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