Mind The Gap! Setting Up A Code Structure Building Bridges

(1)

(2)

Mind The Gap!

Setting Up A Code Structure

Building Bridges

(3)

(4)

Why do we need architecture?

Complex business problems

too many details to keep overview

Making „

big

“

problems

„

smaller

“

Separation of higher level aspects and their relations Create abstract views with less details

(5)

Why do we need architecture?

Functional view

Components Layers

Cross-cutting concerns Dependencies

Non-Functional view

Scalability Robustness Security

(6)

Architect‘s

view

…

(7)

(8)

Different roles

same objects, different views

The Gap

Diagram vs. Code

Architect vs. Developer

Architect Developer

Representation Diagram Code (Text)

Scope Broad Narrow

Detail level Low (abstract) High (concrete)

(9)

Representation of architecture in code structures

Language elements with additional roles

Package Layer Class Service

…

But: abstractions are not visible in code

How does the developer know about it?

Does even the architect know about it?

(10)

(11)

Example

–

Yet Another Web Shop

High level functional requirements

User management Product catalog Shopping cart Order-/payment Shipping

High level non-functional requirements

Maintainable Scalable

(12)

Technology

Java EE

Shop shop.war Container

Deployable (Artifact)

(13)

Deployment vs. Non-Functional Requirements

Scalability

Availability

Maintainability

Artifacts

(14)

Deployable artifact per component

shop/

pom.xml user/ pom.xml catalog/ pom.xml cart/ pom.xml order/ pom.xml shipping/ pom.xml <parent> <groupId>com.acme.shop</groupId> <artifactId>parent</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>user</artifactId> <packaging>war</packaging> <groupId>com.acme.shop</groupId> <artifactId>parent</artifactId> <packaging>pom</packaging> <version>1.0.0-SNAPSHOT</version>

(15)

Layering a component

Root package = com.acme.shop.user

groupId + artifactId

com.acme.shop.user.rest com.acme.shop.user.web

com.acme.shop.user.services.api com.acme.shop.user.services.impl com.acme.shop.persistence.dao com.acme.shop.persistence.model

Dependencies cannot be validated?!

REST API Web UI

Services

Persistence

(16)

Class roles in layers

com.acme.shop.user.rest

JAX-RS resources

com.acme.shop.user.web

Models, views, controllers Validators, converters

com.acme.shop.user.services

EJB

com.acme.shop.persistence.dao

DAOs

com.acme.shop.persistence.model

JPA entities Rules developers should know about

Concepts architects should be aware

(17)

External dependencies of a component

REST API Web UI

Services

Persistence JAX-RS

EJB

JSF

JPA

CDI

DAO Model

(18)

External dependencies

<parent> <groupId>com.acme.shop</groupId> <artifactId>user</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <packaging>war</packaging> <dependencies> <dependency> <groupId>javax.faces</groupId> <artifactId>faces-api</artifact> <version>2.2</version>

<scope>provided</scope>

</dependency> </dependencies>

Provided by container Valid for all components

(19)

Dependency Management

<groupId>com.acme.shop</groupId> <artifactId>parent</artifactId> <version>1.0.0-SNAPSHOT</version> <packaging>pom</packaging>

<groupId>javax.faces</groupId> <artifactId>faces-api</artifact> <version>2.2</version>

<scope>provided</scope> </dependency>

</dependencies>

(20)

Using managed dependencies

<version>1.0.0-SNAPSHOT</version> </parent>

<groupId>javax.faces</groupId> <artifactId>faces-api</artifact> </dependency>

(21)

Dependencies between components

user

catalog

order cart

shipping

Synchronuous - REST Asynchronuous - JMS

(22)

Dependencies between components

Communication via remote protocols

REST over HTTP JMS

Compile time dependencies

not explicitly required… …but convenient!

Re-use code

Shared artifacts, i.e. libraries APIs, domain models

(23)

Splitting up a component

shop/

pom.xml user/ pom.xml api/ pom.xml app/ pom.xml

Visibilities

api public app private <parent> <groupId>com.acme.shop</groupId> <artifactId>shop</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>user</artifactId> <packaging>pom</packaging> <parent> <groupId>com.acme.shop</groupId> <artifactId>user</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>user.api</artifactId> <parent> <groupId>com.acme.shop</groupId> <artifactId>user</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>user.app</artifactId> <packaging>war</packaging>

(24)

Splitting up a component

(25)

Use API of another component

(26)

Deployment of libraries

Option: API versioning

Cart 2.1.0 Application User 1.0 API Requires further component separation

user.app.war cart.app.war

user.api.jar cart.api.jar user.api.jar

(27)

Common functionality

common-core-shared-util-helper

Big balls of mud

Cover mostly technical aspects

layers

shop/

common/ pom.xml rest/ pom.xml web/ pom.xml services/ pom.xml persistence/ pom.xml user/ <parent> <groupId>com.acme.shop</groupId> <artifactId>common</artifactId> <version>1.0.0-SNAPSHOT</version> </parent> <artifactId>common.web</artifactId> <dependencies> <dependency> <groupId>javax.faces</groupId> <artifactId>faces-api</artifactId> </dependency> </dependencies>

(28)

Component configuration

Artifacts that need to be delivered with deployables

Property-, XML, YAML-files, etc... Migration scripts

user/

pom.xml api/

pom.xml app/

pom.xml config/

pom.xml

Deliverable artifacts (JAR, ZIP)

(29)

Test code

Part of architecture

shop/

test

*ST.java Components user/test

*CT.java Mockito

Component stubs user/app

*Test.java Mockito

Unit Component

(30)

Component stubs

Component tests require

…

API and implementation of own component APIs of other components

Stubs for other components

Stubs can be provided per owning component

user/test

src/main/java

com.acme.shop.user.test.UserManagementStub.java

(31)

Structural overview

shop/

common rest web services persistence test user api app config test … Libraries Components with similar structures

(32)

Structural overview (continued)

… cart api com.acme.shop.api app com.acme.shop.rest com.acme.shop.ui com.acme.shop.services com.acme.shop.persistence config test … test

Layering in component with defined content &

dependencies

Component test

(33)

Some Observations

It‘s

an evolution

Neither architecture nor code structures are static

Deployment is the starting point

Separate following requirements

Architecture is not only about packages

Build system defines core dependencies

Different roles

–

different views

(34)

(35)

The Gap

Code

Architecture Development

Test Build-/Integration

-management

Different Roles Different Views Different Interests

(36)

Spread The Knowledge

Mr. Project Lead: Tear down these walls!

Cross-functional teams Architect != Architect

Project vs. Enterprise Work together

Pair Programming Reviews

Establish rules

(37)

Spread The Knowledge

Documentation

Word Documents UML Diagrams Wiki

...

Keep documentation as close as possible to code! Store in version control system

(38)

Challenges

Structures and rules are dynamic

Documentation is always out-of-date

Teams change

(39)

Spread The Knowledge!

Static code analysis

Define structural rules Break build on violations

Provide reasonable feedback to developers

Which Tool?

SonarGraph Degraph jQAssistant

(40)

jQAssistant

Open Source

http://jqassistant.org Based on Neo4j

Scan software structures during the build

Packages, Classes, Fields, Methods Maven artifacts and dependencies

Analyze

Apply concepts

Package „com.acme.shop.cart“ = Component „Cart“

Verify constraints

Component „Cart“ can only depend on components „User“, „Catalog“ and „Order“

(41)