Architecting well-structured Java applications

ARCHITECTING WELL-STRUCTURED JAVA
APPLICATIONS
Eduards Sizovs
@eduardsi

MOST APPS BEGIN LIFE SMALL AND NEAT.

HELLO. I AM YOUR ROTTING ENTERPRISE APP.

- RIGIDITY
- FRAGILITY
- IMMOBILITY
- VISCOSITY
- OPACITY
- NEEDLESS COMPLEXITY
- NEEDLESS REPITITION
SMELLING SYMPTOMS ->

A JDK CODE BASE IS DEEPLY INTERCONNECTED AT BOTH THE API AND THE
IMPLEMENTATION LEVELS, HAVING BEEN BUILT OVER MANY YEARS
PRIMARILY IN THE STYLE OF A MONOLITHIC SOFTWARE SYSTEM. WE’VE
SPENT CONSIDERABLE EFFORT ELIMINATING OR AT LEAST SIMPLIFYING AS
MANY API AND IMPLEMENTATION DEPENDENCES AS POSSIBLE, SO THAT
BOTH THE PLATFORM AND ITS IMPLEMENTATIONS CAN BE PRESENTED AS A
COHERENT SET OF INTERDEPENDENT MODULES, BUT SOME PARTICULARLY
THORNY CASES REMAIN.
(C) MARK REINHOLDS, CHIEF ARCHITECT OF THE JAVA PLATFORM

PACKAGE IS THE FIRST-CLASS CITIZEN AND
KEY ELEMENT OF LOGICAL DESIGN.

TREAT PACKAGES AS A HIERARCHY EVEN IF
THEY’RE REPRESENTED FLAT.

io.shwitter.user
io.shwitter.user.registration
io.shwitter.user.profile
io.shwitter.timeline

io.shwitter.user (part of)

io.shwitter.user
io.shwitter.user.registration (part of)

io.shwitter.user
io.shwitter.user.profile (part of)

io.shwitter.user
io.shwitter.timeline (part of)

USE PACKAGES TO GROUP FUNCTIONALLY-
RELATED ARTIFACTS. DO NOT GROUP
ARTIFACTS THAT DO THE SAME THING, BUT
ARE DIFFERENT BY NATURE.

io.shwitter.controller
io.shwitter.dao
io.shwitter.domain
io.shwitter.services
io.shwitter.exceptions

io.shwitter.controller
io.shwitter.dao
io.shwitter.domain
io.shwitter.services
io.shwitter.exceptions
io.shwitter.user

- ABILITY TO DISTRIBUTE YOUR LAYERS OVER MULTIPLE PHYSICAL TIERS (HA-HA)

- DECOUPLING / ABSTRACTING FOR EXHANGEABILITY (HA-HA)

- DECOUPLING / ABSTRACTING FOR INDEPENDENT EVOLUTION (HA-HA)

- DECOUPLING FOR REUSE (HA-HA)

- SEPARATION OF CONCERNS (IS PARTICULAR LAYER OUR CONCERN?)

- RELATED STUFF CO-LOCATION (ARE DAOS REALLY RELATED?)

- RELATED STUFF CO-LOCATION (ARE DAOS REALLY RELATED?)
- CONSTRAINT ENFORCEMENT (IS THERE A BETTER WAY?)

APPLY SERVICE-ORIENTED MINDSET TO
SOFTWARE STRUCTURE.

LAYERING IS YOUR SERVICE'S DETAIL AND IS
INTERNAL TO THE SERVICE.

GROUP TIGHTLY COUPLED CLASSES
TOGETHER. IF CLASSES THAT CHANGE
TOGETHER ARE IN THE SAME PACKAGE, THEN
THE IMPACT OF CHANGE IS LOCALIZED.
- THE COMMON CLOSURE PRINCIPLE

MAKE PACKAGES HIGHLY COHESIVE BY
FOLLOWING SINGLE RESPONSIBILITY
PRINCIPLE.

io.shwitter.user.notifications
io.shwitter.user.profile.blocking

io.shwitter.user.notifications
io.shwitter.user.profile.blocking
io.shwitter.user :(

KEEP PACKAGES LOOSELY COUPLED, IDEALLY
– COMPLETELY INDEPENDENT. REFLECTION
DOESN’T COUNT.

package io.shwitter.user
@Entity
class User {
// name, password etc.
}
package io.shwitter.timeline
@Entity
class Timeline {
@OneToOne User user;
}

@Embeddable
class UserId {
Long value;
}
package io.shwitter.timeline
@Entity
class Timeline {
@Embedded UserId userId;
}

PROVIDE SLIM PACKAGE INTERFACE AND HIDE
IMPLEMENTATION DETAILS.

AVOID DEPENDENCY MAGNETS. SOMETIMES
DUPLICATION IS NOT THAT EVIL.

MANAGE RELATIONSHIPS. EVERY
DEPENDENCY ARROW HAS A REASON.

FINDBUGS V1.1 – IMPERFECTION CREEPS IN

FINDBUGS V1.2 – IMPERFECTION TAKES HOLD

FINDBUGS V1.3 – CHAOS BEGINS

THE DEPENDENCIES BETWEEN PACKAGES
MUST NOT FORM CYCLES. BURN BI-
DIRECTIONAL DEPENDENCES IN FIRE.

MERGING
class User {
void register(RegistrationNotifier notifier) {}
}
package io.shwitter.user.notify
class RegistrationNotifier {
void notify(User user) {}
}

MERGING - REPACKAGING
class User {
}
}

DEPENDENCY INVERSION
class User {
}
}

DEPENDENCY INVERSION - REFACTORING STEP 1
class User {
}
class RegistrationNotifier implements UserNotifier {
}
interface UserNotifier {
}

class User {
void register(UserNotifier notifier) {}
}
}
}

ESCALATION
class User {
void register(Notifier n) { n.notify(this); }
}
class Notifier {
void notify(User user) { sendEmailTo(user.email()); }
}

ESCALATION - REFACTORING STEP 1
class User {
}
class Notifier {
}
package io.shwitter.user.registration
class Registrator {
void register(User user, Notifier n) {}

class User {
void register() { }
}
class Notifier {
}
class Registrator {
void register(User user, Notifier n) { n.notify(user); }

class User {
void register() { }
}
class Notifier {
void notify(String emailAddress) { sendEmailTo(emailAddress); }
}
class Registrator {
void register(User user, Notifier n) { n.notify(user.email()); }

DEMOTION
class User {
}
class Notifier {
}

DEMOTION - REFACTORING STEP 1
class User implements EmailHolder {
}
class Notifier {
}
package io.shwitter.emailer
interface EmailHolder {
String email();

DEMOTION - REFACTORING STEP 2
class User implements EmailHolder {
}
class Notifier {
void notify(EmailHolder emailHolder) { sendEmailTo(emailHolder.email()
}
package io.shwitter.emailer
interface EmailHolder {
String email();

OO Design Principles & Metrics, Jason Gorman http://goo.gl/RTW9GT
The Economics of Software Design, J.B. Rainsberger http://goo.gl/ra7Q8Q
SOLID Principles, Eduards Sizovs http://goo.gl/Rpxavd
Designing Object-Oriented Software, Jouni Smed http://goo.gl/iyE1R2
Grand Unified Theory Of Software Design, Jim Weirich http://goo.gl/ASqyAs
Fun With Modules, Kirk Knoernschild http://goo.gl/i8jx8Y
Patterns of Modular Architecture http://goo.gl/yFqmZO
Let’s turn packages into a module system! http://goo.gl/Mzco8F
MORE

EITHER YOU WORK TO CREATE A
SOFTWARE STRUCTURE OR YOU DON'T.
EITHER WAY A STRUCTURE WILL EMERGE.
@EDUARDSI

Architecting well-structured Java applications

Architecting well-structured Java applications

More Related Content

Similar to Architecting well-structured Java applications

More from Eduards Sizovs

Recently uploaded

Architecting well-structured Java applications