business driven architecture

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. ▪ vinay@visionjockeys.com▪ 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”

?▪ vinay@visionjockeys.com

▪ https://github.com/vshivaswamy

▪ http://vinayshivaswamy.blogspot.com/