1. Notes on
Architecture
Dr. Joonas Lehtinen
Founder & CEO / Vaadin

2. Structure [only]
when needed

5. Nightmare

6. Dream

7. Last name
varchar: !
LAST_NAME

8. Software architecture
danger #1
Prepares for expansion and
changes that will never happen
Overdesigned
architecture
Tries to achieve faulttolerance or scalability
never needed
Increases risks by making
implementation complex

9. If you are not 100%
sure that a
requirement is solid,
choose a simpler
structure even when
the requirement night
not be fulfilled

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

11. Learn to
estimate and
communicate
cost impacts to
negotiate
requirements

12. Overgeneralization

16. Customization by Programming
Card UI
Example
System
Integration
Example
DataSource
Example
Custom
Card UI
External
System
Custom
DataSource
Web
Browser
Customization by Configuring
Millstone Cards 2.0
Settings
(XML)
Theme
(HTML,
CSS, ...)
SQL DB
Report
(XSL)
External
Reporting
System
Settings
Example
Theme
Example
Report
Example

17. Software architecture
danger #2
Claims that your software can
do thinks that you do not know
Overgeneralization
Moves the unknown to
layers where it should not
be (UI or user)
Tries to overcome unknown
requirements

18. Decoupling
tries to reduce complexity
by adding complexity

22. You are now
do
prepared to
I really
change a
need to
meatball change it?

24. Two edged sword of
software architecture
Can make your system easier to
understand (modules decoupled)
De-coupling
Can make your system harder
to understand (more modules
and interfaces)
Will make your system
slower to build, but could
make it easier to maintain

25. Decouple only things
that should be built
separately.
!
Decouple for
readability, not for
potential change.

26. For the love of
Refactoring

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

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

29. 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

30. Art of naming

32. One of the hardest tasks
Critical for clarity
Naming
Takes a lot of time
when done properly
Should be debated in code review
Sign of a good architecture

33. Follows project
style
Short
Documents the described thing
Good name
Intuitive
Unique (for project and domain)

34. Design patterns
are dynamite

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

37. Powerful tool
!
Never use when not
100% sure that needed
!
Disastrous in
inexperienced hands

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

39. UX and SA
go hand in hand

40. Requirements
wireframes and
interaction design
software
architecture
code

42. Performance
is not an afterthought

43. HOWTO not fail with
performance
Define
performance
Measure
performance
!
!
• Customer
requirement
• Performance goal
is a number
• Performance has
a cost
• Benchmark
regularly
• Start measuring
before app is built
• React regressions
immediately

45. Architecture for a
Library

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

47. Someone else's application
Your library
depends on
Public Architecture!
+!
API
depends on
Internal Architecture!
+!
API

48. 2001

49. Web-browser
Http-req.
XHTML
Millstone
Web Adapter
State change
Data source
UI
Component
Event
2003
XML
Change
Application
logic

50. 2013

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

52. Architect who is
not a developer is
not an architect

54. ?
joonas@vaadin.com
vaadin.com/joonas
@joonaslehtinen