A collective thought process to apply application architecture and design into code to deliver business value in development agility. This presentation is about defining an application architecture and how to enforce design in the code. Design is an art and so how effectively we design our code to componentize the code base to focus on business values rather than dummy layers. Importance of Modularity and how it helps drive the development as well as delivery more effectively.

1. BUSINESS DRIVEN ARCHITECTURE
CHICAGO CODER CONFERENCE 6’TH JUNE, 2016 VINAY SHIVASWAMY

2. ROADMAP
▪ Application Development methodology
▪ Application Architecture
▪ Application Design
▪ Application Code
▪ Demo
▪ Conclusion
▪ Q&A

3. WHO AM I
▪ Technology expert with over 20 years of experience as an Architect, Manager and
Developer using Java EE and wide variety of open source technologies and
environments.
▪ My expertise is in agile development methodology with focus on test driven
development, Continuous Integration and Continuous Delivery model.
▪ TOGAF Certified Enterprise Architect and Certified Scrum Master.
▪ vinay@visionjockeys.com
▪ https://www.linkedin.com/in/vinayshivaswamy
▪ http://vinayshivaswamy.blogspot.com/
▪ https://github.com/vshivaswamy
“Long Live Continuous Delivery”

4. DEVELOPMENT METHODOLOGY
• Agile Software Development Methodology
Working Software
Responding to
Change

5. AGILE SOFTWARE DEVELOPMENT
▪ Principles Behind The Agile Manifest
Welcome Changes
Technical Excellence &
Good Design
Architecture &
Design Emerge
Deliver Frequently

6. APPLICATION ARCHITECTURE
KEY ATTRIBUTES OF ARCHITECTURE
▪ Reliability
▪ Availability
▪ Maintainability
▪ Scalability
4 C’S OF ARCHITECTURE
▪ Connectivity
▪ Constraints
▪ Complexity
▪ Changeability

7. APPLICATION ARCHITECTURE
…Dependency Management

8. APPLICATION DESIGN
EXTERNAL DEPENDENCIES
▪ Java Archives
▪ Maven
▪ Gradle
INTERNAL DEPENDENCIES
▪ Package
▪ Annotations
▪ Class
▪ DI – @Autowired, @Service, @Component

9. APPLICATION DESIGN
▪ Domain Driven Design
Demo
Domain
Vendor
CustomerAccount

10. APPLICATION DESIGN
 Modules
 Layers
 Vertical Slices
 Subsystems

11. APPLICATION CODE
▪ Enforce design in the code
▪ Design is preserved
▪ OO Principles
▪ Polymorphism & Encapsulation
▪ Composition over Inheritance
▪ Cohesion & Coupling

12. APPLICATION CODE
▪ Class – SOLID Principles
S The Single Responsibility Principle A class should have one, and only one, reason to change.
O The Open Closed Principle You should be able to extend a classes behavior, without
modifying it.
L The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
I The Interface Segregation Principle Make fine grained interfaces that are client specific.
D The Dependency Inversion
Principle
Depend on abstractions, not on concretions.

13. APPLICATION CODE
▪ Package – RCC Principles
R The Release Reuse Equivalency
Principle
The granule of reuse is the granule of release.
C The Common Closure Principle Classes that change together are packaged together.
C The Common Reuse Principle Classes that are used together are packaged together.

14. APPLICATION CODE
 Simple CRM Application

15. APPLICATION LAYERS
Web
Service
Persistence
Domain

16. APPLICATION SLICES
16
A
c
c
o
u
n
t
C
u
s
t
o
m
e
r
C
O
M
M
O
N
C
o
m
m
o
n
V
e
n
d
o
r

17. APPLICATION SUBSYSTEMS
Web
Service
Persistence
Domain
A
c
c
o
u
n
t
C
u
s
t
o
m
e
r
C
o
m
m
o
n
V
e
n
d
o
r

18. LAYERS
▪ .layer.slice?
▪ .service.account
▪ .dao.account
▪ .slice.layer?
▪ .customer.service
▪ .customer.dao
▪ .slice?
▪ .account
▪ .customer

19. LAYERS
▪ Well Understood with developer community
▪ Violates clean code principles – Reduced cohesion and Increased coupling
▪ Packages are obsolete, classes and methods are forced to expose to public.
▪ Implementation details ahead of abstraction.
▪ Redundant layer information both at package level and class level
▪ Not associated with any business value directly.

20. SLICES
▪ Different thinking
▪ Enforces cleaner code
▪ High cohesion and less coupling
▪ Meaningful sonar dashboard package cycle, dependency index numbers
▪ Higher level of abstraction
▪ Encapsulation at the package level.
▪ Breaks the complex system into subsystems
▪ Application code is self documenting
▪ Associated with business value.

21. DEMO

22. CONCLUSION
▪ “Focus on delivering Business Value”
▪ “Modularize your application”
▪ “Start with less packages, least visibility”

23. ?
▪ vinay@visionjockeys.com
▪ https://github.com/vshivaswamy
▪ http://vinayshivaswamy.blogspot.com/