Dr. Joonas Lehtinen Founder & CEO / Vaadin

Notes on Architecture

Structure [only] when needed

Nightmare

Dream

Last name

varchar: !LAST_NAME

Over-designed architecture

Increases risks by making implementation complex

Tries to achieve fault-tolerance or scalability never needed

Prepares for expansion and changes that will never happen

Software architecture danger #1

If you are not 100% sure that a

requirement is solid, choose a simpler

structure even when the requirement night

not be fulfilled

All requirements having an impact on architecture must have clear metrics and goals

Learn to estimate and communicate cost impacts to negotiate requirements

Overgeneralization

Custo

miz

ation b

y P

rogra

mm

ing

Custo

miz

ation b

y C

onfiguring

Report(XSL)

ReportExample

Millstone Cards 2.0

CustomCard UI

External System

Custom Data-

Source

Settings(XML)

Theme(HTML, CSS, ...)

SQL DBWeb

Browser

External Reporting System

SettingsExample

ThemeExample

Card UIExample

System Integration Example

Data-Source

Example

Millstone Cards 2.0 Structure

Over-generalization

Tries to overcome unknown requirements

Moves the unknown to layers where it should not be (UI or user)

Claims that your software can do thinks that you do not know

Software architecture danger #2

Decoupling tries to reduce complexity by adding complexity

You are now prepared to change a meatball

do I really

need to change it?

De-coupling

Will make your system slower to build, but could make it easier to maintain

Can make your system harder to understand (more modules and interfaces)

Can make your system easier to understand (modules decoupled)

Two edged sword of software architecture

Decouple only things that should be built

separately. !

Decouple for readability, not for potential change.

For the love of Refactoring

Refactoring is very cheap. Rewriting (working parts) is cheaper than you think. Cleaning up the mess late never happens. Keep your room tidy!

#1 Choose a statically typed language or loose refactoring tooling support

Start with the simplest possible architecture. !

When you realize you need to work around your own architecture to add features, or it is impossible to add new features, or you don't know how to model your new features on top of the architecture - refactor!

- Petter Holmström

Art of naming

Naming

One of the hardest tasks

Critical for clarity

Takes a lot of time when done properly

Should be debated in code review

Sign of a good architecture

Good name

Short

Documents the described thing

Unique (for project and domain)

Intuitive

Follows project style

Design patterns are dynamite

design pattern is a general reusable solution to a commonly occurring problem within a given context [in software design]

Powerful tool !

Never use when not 100% sure that needed !

Disastrous in inexperienced hands

Experts trying to save your project after too many design patterns in wrong places

UX and SA go hand in hand

wireframes and interaction design

code

software architecture

Requirements

Performance is not an afterthought

HOWTO not fail with performance

Define performance !• Customer

requirement • Performance goal

is a number • Performance has

a cost

Measure performance !• Benchmark

regularly • Start measuring

before app is built • React regressions

immediately

Architecture for a Library

"Don't ever code anything which has public API. You will be sorry"

- Artur Signell

Internal Architecture!+!

API

Public Architecture!+!

API

Your

libr

ary

Someone else's application

depends on

depends on

2001

UIComponent

MillstoneWeb Adapter

Applicationlogic

Web-browser

XHTMLHttp-req.

XMLState change

ChangeEvent

Data source

2003

2013

When you do not know how it should work, please do not hide it behind an abstraction

Architect who is not a developer is not an architect

? joonas@vaadin.com vaadin.com/joonas

@joonaslehtinen