Software systems evolve over time. Most of them through, are quick and small ones - hacks. These changes, over a period of time makes the code spaghetti, difficult to understand, gathers tremendous Technical Debt and along they way looses the design principles by which they are designed in the first place. Fixing these problems will be risky, tedious and expensive and definitely not without the support of a proven framework.This is the first problem. There is another force that will require significant changes to existing software systems. This force is created by the changing landscape of expectations due to technologies such as cloud, big-data and REST as well as emotional experience across all touch points, not just on PCs. This is the second problem. Modular architecture addresses both these problems. It is not a novel thought or an isolated architectural style, but a structured way to refactor, rather restructure the code to make the systems easier to understand, extend and adopt to the new paradigms. The focus of Modular Architecture is the structural and physical design.

1. MODULAR
ARCHITECTURES
By Param Rengaiah (@its_param)
March 18, 2014
What they are and why do they
matter now.

2. PROLOGUE
History matters, at least to me.

5. This is a three part story.

6. PART I
Definition, Sort of.

7. What is
Software
Architecture?

8. The word software architecture intuitively
denotes the high level structures of a
software system.
- Wikipedia
“

9. 1 STRUCTURE
OF THE SYSTEM

10. 2 PROCESS
OF CREATING SUCH STRUCTURES

11. 3 RECORD
OF THIS STRUCTURE

12. STYLES
Architecture are indicated in terms of their

13. MANY
STYLES
An useful system always uses

14. LAYERED
STYLE 1

16. PHYSICAL
LAYOUT
Focuses on

17. SERVICE
ORIENTED
STYLE 2

19. INTEGRATION &
CUMMINICATION
Focuses on

20. What is
Modular
Architecture?

21. GOING ONE
STEP
FURTHER
Modular Architecture is

22. SMALLER
MODULES
Dividing a layer or a service into

23. deployable, manageable,
natively reusable, composable,
stateless unit of software that
provides a concise interface to
consumers.
- Kirk Knoernschild
MODULE IS A
“

24. CHARACTERISTICS
Of a module are

25. 1 PHYSICAL
SHOULD BE

26. 2 SCOPE
CLEAR BUSINESS

27. 3 LAYERS
CONFINES WITHIN EXISTING

28. 4 CONTEXT
WORKS WITHIN ITS

29. 5 RATE OF
CHANGE
SCOPED BY

30. 6 INTERFACE
EXPRESSED THROUGH PUBLIC

31. 7 STATELESS
MODULE INTERFACES ARE

32. JAR
A module in Java can be expressed as

34. COMPOSITION &
COMPREHENSION
Focuses on

35. BENEFITS
Of Modular Architectures

36. 1 UNDERSTAND
HELP US

37. 2 EXTENDING
MAKES IT EASY FOR

38. 3 DEPENDENCY
HELP US MANAGE

39. Enabling us to

40. ARCHITECT ALL
THE WAY DOWN

42. Provide us with

43. DESIGN TIME
MODULARITY

44. RUNTIME
MODULARITY

45. But my system is already modular.

46. FRAMEWORK
DOES NOT MAKE CODE MODULAR

47. A NEW LANG
DOES NOT MAKE CODE MODULAR

48. SOA
DOES NOT MAKE CODE MODULAR

49. PRETTY DIAGRAM
DOES NOT MAKE CODE EASY TO
UNDERSTAND

50. PHYSICAL DESIGN
IS THE ONLY THING THAT HELP YOU
UNDERSTAND, EXTEND AND MANAGE.

51. PART II
Prerequisites, Sort of.

52. But why would we want to restructure in the first
place?

53. VISION
ARCHITECTS

55. RESULT IS?

57. REALITY IS
After a year or so,

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

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

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

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

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

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

68. Restructuring addresses

69. 1 LOGICAL
DESIGN FLAWS

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

71. 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

72. 2 PHYSICAL
& STRUCTURAL DESIGN FLAWS

73. Restructuring to Modularity.

74. I was fortunate to have these …

75. 1 MODULARITY
PATTERNS
A BOOK ON

77. 2 UI MODULE
SEPERATE

78. GWT

79. 3 DOMAIN
MODEL
SEPERATE

80. Ubiquitous Language

81. 4 EXTERNAL
INTEGRATION
ISOLATED

82. Clear business context.
Explicit boundary.
Physical adapters.

83. 5 RULES &
WORKFLOW
GROOVY BASED

84. Essential Complexity
Vs
Accidental Complexity
Choice between

85. 6
DESIGN &
ARCH
REVIEWS
PERIODIC

86. Making choices under
given context and
constraints.
Architecture is about

87. 7 TRUST & FAITH
STAKEHOLDERS SHOULD HAVE

88. Trusting is one thing, but
keeping you on the toe is
another.

89. 8 IMPL TEAM
ROCK STAR

90. Willing to unlearn what you
have known for years.

91. PART III
The works, if you say so.

92. 16 to 82
Number of JAR modules

93. How did we do it?

94. Arrive at a “Ubiquitous
Language” for the domain
model.

95. Simply the lifecycle of
managed resources.

96. Catalog the lifecycle
events, triggers, contexts
and swim-lanes.

97. Refactor the domain model
to confer to the new
ubiquitous language.

98. Extract core domain model
and reference models as
separate modules.

99. Create a separate module
to manage each stage of
lifecycle for each resource.

100. Divide the modules further
consider rate of change,
rate of reuse and for
removing cyclical
dependencies.

101. Create a contract module
for each external system
as it relates to your
business

102. For each of above logical
modules, create two
physical modules - a spec
and an implementation.

103. Manage physical
dependencies through
spec modules.

104. Create deployable modules
as a composition of smaller
modules (WAR).

105. Deployed module
endpoints are exposed as
stateless REST APIs.

106. Composition provides
runtime inter-module
integrations.

107. Composition essentially
addresses time and space.

108. Scalability is baked into
composition.

110. You will arrive at an event-driven, message-driven,
comprehensible, extensible, scalable and
maintainable system.

111. EPILOGUE
Why does it matter now? Finally.

112. Have you been asked to do any of this?

113. LETS ADD A MOBILE
SKIN

114. WE SHOULD
SUPPORT TOUCH
DEVICES

115. PUT IT ON THE
CLOUD

116. 100% SOA

117. ITS A SAAS APP
BABY!

118. WE SUPPORT BIG
DATA

119. WE DID
“RESPONSIVE WEB
DESIGN”

120. Modular Architecture prepares you for the future.

121. Talking about new trends..

122. REACTIVE
ARCHITECTURE

123. Modular Architecture is an essential facet of
RESPONSIVE ARCHITECTURE.

124. Thank You.
Follow me at @its_param