Hugtakið hugbúnaðararkítektúr er yfirhlaðið orð og þýðir mismunandi hluti fyrir mismunandi fólk. Við ætlum í þessum fyrirlestri að skilgreina ýmis hugtök tengd arkítektúr til að fá betri skilning á þessu. Við munum einnig skilgreina hvað agile arkítektúr þýðir eða hvað það þýðir ekki. Þá skoðum við monolith arkítektúr sem er hinn hefðbundi arkítektúr sem flestir nota í dag. Vandinn er sá að í dag eru kröfurnar meiri en þessi arkítektúr ræður við og því hafa menn verið að skoða aðrar leiðir eins og lightweight Service Oriented Architecture og hvernig smíða má hugbúnað sem þjónustur eða microapps eða microservice. Við skoðum einnig lagskiptingu en það er elsta trikkið í bókinni og byggir á deila og drottna aðferðinni.

1. Lecture 02
Architecture

2. Agenda
 Building blocks (recap)
 Architecture
 Monolithic Architecture
 Service Oriented Architecture
 Layering

3. Reading
 Brown 1, 2, 3 og 4
 Pattern: Monolithic Architecture
 Decomposing applications for scalability and
deployability
 The Scale Cube

4. Building Blocks

5. Building Enterprise Applications
 Building computer systems is hard
Design
Pattern
Architecture
Middleware
Frameworks
OO
Programming

6. Architecture
 Shared understanding of system’s design by the expert
developers on a project
– Highest-level breakdown of a system into its parts
– Decisions that are hard to change
 Architecture influences design
of components, technology,
performance and middleware
 There are always options

7. Object Oriented Programming
 OO is key to development of systems
– Design for reusability, flexibility and performance
“OO design is more important than specific technologies, such as J2EE. We
should try to avoid letting our technology choices, such as J2EE, constrain
our ability to use true OO design”
– Rod Johnson “If the design is good, there is no code”
– Jónas Þór, Senior Betware developer
 One of the biggest hurdles for developers
– Each component should be simple with simple task
– Involves understanding of interaction of parts

8. Design Patterns
 Design using known ideas
– Design patterns are standard solutions to common problems
in software design
– Systematic approach for problems that reoccur in software
development
– Patterns have name and definitions - not language dependant
 History
– Landmark book from 1995: Design Patterns: Elements of
Reusable Object-Oriented Software Gang of Four (GoF)

9. Middleware
 Enterprise system are built on middleware
– Can cover a broad spectrum of software and generally sits
between an application and an operating system
– For example, databases, application servers, web servers,
messaging systems, transaction monitors
– “The plumbing” – the infrastructure
 Horizontal market
– Solves common problems – not specific business requirements
– Low-level system

10. Frameworks
 Frameworks define the support structure for how to
organize and build systems
– Can improve productivity
– We can use existing frameworks or build our own
 Frameworks implement common problems
– Developers extend and add their business requirements
 Framework design
– Use inheritance, inversion of control, interfaces and helper
classes
– Implement design patterns

11. QUIZ
Which of the following statement is not true?
A) Design patterns are solutions to common problems
B) Object oriented programing is good for general problems
C) Frameworks are used to increase productivity
D) Middleware can solve business related problems

12. QUIZ
Which of the following statement is not true?
A) Design patterns are solutions to common problems
B) Object oriented programing is good for general problems
C) Frameworks are used to increase productivity
D) Middleware can solve business related problems
✔

13. Architecture

14. Architecture
 Means different things to different people
– Big picture,
things difficult to change,
– a plan,
a blueprint…

15. Architecture – noun
The decomposition of a
product into a collection of
components/modules and
interactions
Structure

16. Architecture – verb
Understanding what you
need to build, create a
vision and making the right
decisions
Vision

17. Types of Architecture
 There are many different architectures
– Network, security, data, hardware, enterprise…
 All have structure and vision
– All have multiple constraints such as cost, time, legal, regulatory

18. Application Architecture
 Application is the focus
– Contains classes, components, design patterns, frameworks,
libraries
– Lower-level aspects of software design
– Concerned with sign technology stack and layering
Client
REST Services
EJB3
Hibernate
Oracle
Client
REST layer
Service layer
Domain Layer
Database layer

19. System Architecture
 Focus on multiple applications across a number of tiers
and technologies
 Interactions between applications
 Overall structure of the end-to-end software system at
high-level
 Mix of software and hardware

20. Software Architecture
 The combination of application and system architecture
 Includes the technical practices to build the software
– Design Principles, Programming language
Design patterns, Unit testing
and much more…
 Must also include aspects like
– Cross-cutting concerns such as logging and exception handling
Security, Performance, Audit Requirements, constraints,
and much more…

21. Enterprise Architecture
 How the enterprise is broken up in groups/departments
 Business processes used
 Workflows used
 May not look at technology in detail rather how to us
technology across the organization to get work done

22. Agile Architecture
 Agile refers to a methodology of building software
– moving fast, embracing change, release often, feedback cycles
etc.
Does agile development team then build agile
architectures?
 Agile architecture means it can react to change, is easy
to change, is extendable

23. Agility
 Agility means you can use the OODA loop
Observe, Orient, Decide and Act
How Spotify builds products

24. QUIZ
Which of the following architecture descriptions would be concerned with
interactions between applications
A) Application Architecture
B) System Architecture
C) Software Architecture
D) Enterprise Architecture

25. QUIZ
Which of the following architecture descriptions would be concerned with
interactions between applications
A) Application Architecture
B) System Architecture
C) Software Architecture
D) Enterprise Architecture
✔

26. Monolithic Architecture

27. Monolith Architecture
 Traditional approach to building applications
 Chris Richardson: Decomposing applications for
scalability and deployability

29. Monolith Architecture
Bookstore UI
Accounting service
Payment service
Shipping service SQL
Browser Apache

30. Monolith Architecture
 Benefits
– Simple to understand
– Straightforward to develop and test
– One release and deployment
– All linking is a compile type
– Scaling is simple

31. Monolithic Architecture
 Drawbacks
– User interface challenge – old style UI architecture
– Real-time applications (like node.js) don’t fit in easy
– Obstacle to frequent deployment – fear of change
– Overloads your IDE and container – slow build, development
– Obstacle to scaling development teams
– Locks down the technology stack – long term commitment

33. Service Oriented Architecture

34. SOA
 Overload term
– Means different things to different people
– Implies Web Services using SOAP
SOA actually means that components of an
application act as interoperable services, and
can be used independently and recombined into
other applications
Engineering Software as a Service
by David Patterson and Armando Fox

35. Service Oriented Architecture
 Software Architecture where all components are
designed to be services
 Applications composed of interoperable services
– Easy to build new services
– Easy to change
 Parts of the systems need to change more than others

36. Traditional Architecture
Bookstore UI
Accounting service
Payment service
Shipping service SQL
Browser Apache

37. SOA Architecture
Bookstore
Service
Account
service
Payment
service
Bookstore UI
Shipping
service
API

38. Partitioning the Monolith into Services
 One way is to go from Object soup to Services along
domain seams to microservices
From http://www.manning.com/rotem/SOAp_SampleCh01.pdf Arnon Rotem-Gal-Oz’ SOA Patterns figure 1.

39. Microservices or microapps
 Each service can be around 100-200 LOC (lines of code)
– Size not the deterministic factor
– Single Responsibility Principle
– Don’t fix it – rewrite it
 Microservice can have embedded web server
– Totally independent

41. The Scale Cube

42. QUIZ
Which statement is not true about SOA?
A) SOA does not affect performance
B) No service can access other service data except using APIs
C) SOA improves productivity though reuse
D) Monoliths system must deploy all components

43. QUIZ
Which statement is not true about SOA?
A) SOA does not affect performance
B) No service can access other service data except using APIs
C) SOA improves productivity though reuse
D) Monoliths system must deploy all components
✔

45. Bezos’ Mandate (from Yegge’s Rant)
1. All teams will henceforth expose their data and
functionality through service interfaces
2. Teams must communicate with each other through
these interfaces
3. There will be no other form of interprocess
communication allowed

46. Bezos’ Mandate (from Yegge’s Rant)
4. It doesn't matter what technology they use
5. All service interfaces, without exception, must be
designed from the ground up to be externalizable. No
exceptions.
6. Anyone who doesn't do this will be fired.

47. Layering

48. Layering
 Software systems can get complicated
– Abstractions are needed
 Layering provides abstraction by separating computer
systems in layers
– Higher layers use services from
lower layers
– Each layer has dedicated tasks
and hides complexity from upper
layers

49. Benefits of Layering
 You can understand a single layer as a coherent whole
without knowing much about other layers
 You can substitute layers with alternative
implementation of the same basic service
 You minimize dependencies between layers
 Layers make good places for standardization
 Once you have a layer built, you can use it for many
higher-level services

50. Downsides
 Layers encapsulate some, but not all, things well
– Cascading changes
– For example adding a field in the UI requires changes on each
layer
 Extra layers can harm performance
– At every layer things typically need to be transformed from one
presentation to another

51. The Three Layers
 Presentation
– User’s interface to the system
– User can be another system
– Accepts input, displays views
 Domain
– The Application of the system
– The “Business logic”
– Tends to creep into presentation and data source
 Data Source
– Connection to the database
– Also Persistence

52. Summary
 Building blocks can help you
 Architecture comes in many forms
– Application, System, Software, Enterprise
 Monolithic Architecture
– Traditional approach, but getting difficult to scale
 Service Oriented Architecture
– Lightweight SOA, microservices
 Layering
– The oldest trick in the book