business driven architecture
TRANSCRIPT
BUSINESS DRIVEN ARCHITECTURECHICAGO CODER CONFERENCE 6’TH JUNE, 2016 VINAY SHIVASWAMY
ROADMAP▪ Application Development methodology
▪ Application Architecture
▪ Application Design
▪ Application Code
▪ Demo
▪ Conclusion
▪ Q&A
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. ▪ [email protected]▪ https://www.linkedin.com/in/vinayshivaswamy▪ http://vinayshivaswamy.blogspot.com/▪ https://github.com/vshivaswamy
“Long Live Continuous Delivery”
DEVELOPMENT METHODOLOGY
• Agile Software Development Methodology
Working Software
Responding to Change
AGILE SOFTWARE DEVELOPMENT
▪ Principles Behind The Agile Manifest
Welcome Changes
Technical Excellence & Good Design
Architecture & Design Emerge
Deliver Frequently
APPLICATION ARCHITECTUREKEY ATTRIBUTES OF ARCHITECTURE▪ Reliability
▪ Availability
▪ Maintainability
▪ Scalability
4 C’S OF ARCHITECTURE▪ Connectivity
▪ Constraints
▪ Complexity
▪ Changeability
APPLICATION ARCHITECTURE
…Dependency Management
APPLICATION DESIGN
EXTERNAL DEPENDENCIES▪ Java Archives
▪ Maven▪ Gradle
INTERNAL DEPENDENCIES▪ Package
▪ Annotations
▪ Class▪ DI – @Autowired, @Service, @Component
APPLICATION DESIGN▪ Domain Driven Design
DemoDomain
Vendor
CustomerAccount
APPLICATION DESIGN
Modules
Layers
Vertical Slices
Subsystems
APPLICATION CODE▪ Enforce design in the code
▪ Design is preserved
▪ OO Principles▪ Polymorphism & Encapsulation▪ Composition over Inheritance▪ Cohesion & Coupling
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.
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.
APPLICATION CODE Simple CRM Application
APPLICATION LAYERS
Web
Service
Persistence
Domain
APPLICATION SLICES
16
Account
Customer
COMMON
Common
Vendor
APPLICATION SUBSYSTEMS
Web
Service
Persistence
Domain
Account
Customer
Common
Vendor
LAYERS▪ .layer.slice?▪ .service.account▪ .dao.account
▪ .slice.layer?▪ .customer.service▪ .customer.dao
▪ .slice?▪ .account▪ .customer
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.
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.
DEMO
CONCLUSION▪ “Focus on delivering Business Value”
▪ “Modularize your application”
▪ “Start with less packages, least visibility”
▪ https://github.com/vshivaswamy
▪ http://vinayshivaswamy.blogspot.com/