bare-bones software architecture

107
Agile Architecture XP Days 2012 Johannes Brodwall, Chief scientist Exilesoft Global

Upload: johannes-brodwall

Post on 01-Dec-2014

1.890 views

Category:

Documents


2 download

DESCRIPTION

These are my slides from the Bare-Bones Software Architecture course at XP Days Ukraine 2012. The workshop outlines a quick workshop-oriented process for initiating software projects

TRANSCRIPT

Page 1: Bare-Bones Software Architecture

Agile Architecture

XP Days 2012Johannes Brodwall, Chief scientist

Exilesoft Global

Page 2: Bare-Bones Software Architecture

What is an architect?From greek Arkhi-Tecton

Tecton: Builder

Arkhi: Chief.

Like “Arch angel”

Or “Arch villain”

Page 3: Bare-Bones Software Architecture

What is an architect?“Chief builder”

Page 4: Bare-Bones Software Architecture

What is an architect?(Exilesoft definition)

Page 5: Bare-Bones Software Architecture

A solution architect is someone who understands the problem of

the customerand uncovers and

communicatesa feasible solution

Page 6: Bare-Bones Software Architecture

A solution architect is someone who understands the customer’s problem

(including contraints, context, domain knowledge) and uncovers (though a

team effort) and communicates (with credibility) a feasible solution

(primarily, but not exclusively technical)

Page 7: Bare-Bones Software Architecture

Uncover problemvision, stakeholders, usage flow

Describe problemcontext and domain model

Describe solutiondeployment, implementation

model

Page 8: Bare-Bones Software Architecture

• Describing architecture• Simplifying architecture• Delivering architecture

• Delivering software

• Delivering architecture

Page 9: Bare-Bones Software Architecture

Part I:

Page 10: Bare-Bones Software Architecture

Describing architecture

Page 11: Bare-Bones Software Architecture

• Understanding problem• Uncovering solution

• Communicating architecture

Page 12: Bare-Bones Software Architecture

Understanding the problem

Page 13: Bare-Bones Software Architecture

(Tool time)

Page 14: Bare-Bones Software Architecture

For some stakeholder

Who has a responsibility

The Bare-bones architecture workshop

Is a type of activity

Which gives a capability.

Unlike most relevant alternative

This has a distinguishing attribute.

Page 15: Bare-Bones Software Architecture

For __________________

Who ________________

The _________________

Is a _________________

Which ________________.

Unlike ______________________

This _______________________.

Page 16: Bare-Bones Software Architecture

Participant?

Who are they?

What do they do?

Why do they care?

???

Description

Duties

Values

???

Description

Duties

Values

Page 17: Bare-Bones Software Architecture

Example«Smidig» conference application

Page 18: Bare-Bones Software Architecture
Page 19: Bare-Bones Software Architecture

Example vision statement

Page 20: Bare-Bones Software Architecture

For Agile practitioners

Who need to expand on their experience and network

The Smidig conference

Is a networking event

Which connects you with other Agile practitioners.

Unlike traditional conferences

This presents the experience of many people through lightning talks.

Page 21: Bare-Bones Software Architecture

For Conference organizers

Who want to organize a good conference

The Smidig conference app

Is a web application

Which eliminates unnecessary work.

Unlike commercial conference apps

This is optimized for the large number of talks we have and allows us to make changes fast.

Page 22: Bare-Bones Software Architecture
Page 23: Bare-Bones Software Architecture

Example stakeholders

Page 24: Bare-Bones Software Architecture

Speaker

Description• Experienced• New speaker• Passionate

Duties• Register talk• Upload slide• Give talkValues• Constructive feedback

on talk• Easy CfP• Fast answer

Attendee

Description• Knows about agile• Works in project• Norwegian

Duties• Pay for conference• Get approval to go

Values• Easy registration

Organizer

Description• Volunteer• Works in evenings• Has network

Duties• Select talks• Follow up

paymentsValues• Easy selection process• Good information overview• Never lose a participant• Financial transparency

Page 25: Bare-Bones Software Architecture

Sponsor

Description• Busy• Manager• Not very interested

Duties• Provide logo• Pay sponsorship

Values• Informal

communication• Easy evaluation

Page 26: Bare-Bones Software Architecture

Example usage flow

Page 27: Bare-Bones Software Architecture

Attendance

1. Agile project practitioner wants to learn

2. Attendee goes to Smidig website

3. Attendee registers

4. Attendee pays using Paypal

5. Attendee receives confirmation mail

6. Organizer can see the registration

7. Organizer sends reminder email to attendee to come

8. Organizer prints badges for attendees with Print Company

9. Attendee shows up at Smidig and has an excellent time

Page 28: Bare-Bones Software Architecture
Page 29: Bare-Bones Software Architecture

Speaker

1. Agile experts wants to share knowledge

2. Potential speaker goes to Smidig website

3. Potential speaker registers personal info

4. Potential speaker registers talk

5. Potential speaker receives registration confirmation email

6. Organizer sees registered talk and can market speaking opportunities

7. Organizer accepts talk for confence

8. Speaker receives acceptance email– Alternative: Speaker withdraws talk – organizer updates the talk

and selects another

9. Organizer prints badges for speakers

10. Speaker shows up at Smidig and gives talk

Page 30: Bare-Bones Software Architecture

/Understanding the problem

Page 31: Bare-Bones Software Architecture

Uncovering a solution

Page 32: Bare-Bones Software Architecture

Example context model

Page 33: Bare-Bones Software Architecture

Smidig2011.no

Participant Speaker

Organizer

Printing company

Paypal

Page 34: Bare-Bones Software Architecture

Example domain model

Page 35: Bare-Bones Software Architecture

User• Name• Email• Company• Phone• Password• Accepts email?

Registration• Ticket type• Price• Paid amount• Paypal ref• Payment date• Invoice address [optional]

Talk• Title• Description• Tags[]• Slide file• Status : {pending, accept,

reject}• Email_sent• Position

Speaker*

*

Comment• Title• Text• Created date

*

*

Period• Stage• Title• Time of day• Day

*

Page 36: Bare-Bones Software Architecture

Example deployment model

Page 37: Bare-Bones Software Architecture

Heroku

Smtp.dreamhost.com

Paypal

PostgreSQL

Smidig-conference

(Rails)

Web user

Developer

smidigdb

git.herokugithub

git pushgit pushgit pull

html/http

http

smtp

Page 38: Bare-Bones Software Architecture

Example implementation

diagram

Page 39: Bare-Bones Software Architecture

Router

Controller

1. Find controller

2. Dispatch action

Model class3. Find model

Model4. Manipulate model

5.? Save model

Database

View template View template

6. Render model with view template

Page 40: Bare-Bones Software Architecture

Router

/app/controllers

UsersController

1. Find UserController

2. update(id)

/app/models

User class3. find(id)

app/models

User

5. update_attr(params)

6. save

Database

8. Redirect /users/<id>

POST /users/<id>

4. SELECT … FROM users

7. UPDATE users SET …

Page 41: Bare-Bones Software Architecture

Router

/app/controllers

UsersController

1. Find UsersController

2. show(id)

/app/models

User class3. find(id)

UserDatabase

/app/views/users

show.html.erb

5. Render

GET /users/<id>

4. SELECT … FROM users

6. Get attributes

Page 42: Bare-Bones Software Architecture

Alternative

Page 43: Bare-Bones Software Architecture

Browser Smidig2012.no Paypal.com

1. POST /users

2. Redirect to paypalwith return_url and notify_url

3. Perform payment

4. POST /payment_notifications

5. Redirect to return_url

5. GET /user/<id>

Update user info

Show user info

Save user info

Page 44: Bare-Bones Software Architecture

/Uncovering a solution

Page 45: Bare-Bones Software Architecture

Communicating a solution

Page 46: Bare-Bones Software Architecture
Page 47: Bare-Bones Software Architecture

Vision

Stakeholders

Usage flow

Context

Domain model

Deployment

Implementation

Page 48: Bare-Bones Software Architecture

Does the architect have to do this

herself?

Page 49: Bare-Bones Software Architecture

Team effort

Page 50: Bare-Bones Software Architecture
Page 51: Bare-Bones Software Architecture

/Communicating a solution

Page 52: Bare-Bones Software Architecture

/Describing architecture

Page 53: Bare-Bones Software Architecture

Part II:

Page 54: Bare-Bones Software Architecture

Finding the requirements

Page 55: Bare-Bones Software Architecture

I need a volunteer

Page 56: Bare-Bones Software Architecture

For some stakeholder

Who has a responsibilty

The system name

Is a type of system

Which gives a capability.

Unlike most relevant alternative

This has a distinguishing attribute.

Page 57: Bare-Bones Software Architecture

Participant?

Who are they?

What do they do?

What do they care about?

???

Description

Duties

Values

???

Description

Duties

Values

Page 58: Bare-Bones Software Architecture

….

1. Something happens in the real world

2. The event is communicated to the system

3. The system does something

4. Someone does something with the system

5. …

6. …

7. …

8. …

9. …

10. Some goal is achieved

Page 59: Bare-Bones Software Architecture

/Finding requirements

Page 60: Bare-Bones Software Architecture

Part III:

Page 61: Bare-Bones Software Architecture

Describe architecture

Page 62: Bare-Bones Software Architecture

Frugalflights.com1. A customer wants cheap vacations

2. The customer signs up for daily or weekly notifications of special flight offers

3. Periodically the System checks which customers should get notifications

4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system

5. The System notifies customer of any matching offers via SMS• Variation: The System notifies customer of any matching offers via email

6. The customer accepts the offer via SMS1. Variation: The customer accepts the offer on the system website

7. The System books the tickets on behalf of the customer

8. The system confirms the booking by sending an SMS to the customer

9. The customer can at any point see their active offers and accepted offers on the system website

10. The customer enjoys a cheap vacation!

Page 63: Bare-Bones Software Architecture

UserWho are they• …

What do they do?• …

What do they value?• …

UserWho are they• …

What do they do?• …

What do they value?• …

UserWho are they• …

What do they do?• …

What do they value?• …

UserWho are they• …

What do they do?• …

What do they value?• …

Page 64: Bare-Bones Software Architecture

Example context model

Page 65: Bare-Bones Software Architecture

What actors did you mention in scenario?

Page 66: Bare-Bones Software Architecture

Context: Frugalflights.com1. A customer wants cheap vacations

2. The customer signs up for daily or weekly notifications of special flight offers (where?)

3. Periodically the System checks which customers should get notifications

4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system

5. The System notifies customer of any matching offers via SMS• Variation: The System notifies customer of any matching offers via email

6. The customer accepts the offer via SMS1. Variation: The customer accepts the offer on the system website

7. The System books the tickets on behalf of the customer (where?)

8. The system confirms the booking by sending an SMS to the customer

9. The customer can at any point see their active offers and accepted offers on the system website

10. The customer enjoys a cheap vacation!

Page 67: Bare-Bones Software Architecture

Domain: Frugalflights.com1. A customer wants cheap vacations

2. The customer signs up (?) for daily or weekly notifications of special flight offers (=> “create a subscription”?)

3. Periodically the System checks which customers should get notifications

4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system

5. The System notifies customer of any matching offers via SMS (=> “sends notification”?)

• Variation: The System notifies customer of any matching offers via email

6. The customer accepts the offer via SMS (=> “send acceptance”)1. Variation: The customer accepts the offer on the system website

7. The System books the tickets on behalf of the customer

8. The system confirms the booking by sending an SMS to the customer (=> “sends confirmation”?)

9. The customer can at any point see their active offers and accepted offers on the system website

10. The customer enjoys a cheap vacation!

Page 68: Bare-Bones Software Architecture

Example domain model

Page 69: Bare-Bones Software Architecture

What concepts did you mention in

scenario?

Page 70: Bare-Bones Software Architecture

Example deployment model

Page 71: Bare-Bones Software Architecture

Which servers are involved in

production?

Page 72: Bare-Bones Software Architecture

Example implementation

diagram

Page 73: Bare-Bones Software Architecture

How does the code work?

Page 74: Bare-Bones Software Architecture

Statnett electricity reserves1. Grid operator want to maintain balance of electric production and consumption

2. Power producer sends unused capacity (reserves) per hour for each power plant to LARM using EDIFACT via Sterling Integrator

– Detail: The capacity “line” has a price– Detail: Each plant may have several capacities at different prices– Detail: Capacity may be to increase or to decrease production

3. A spike occurs in the consumption or production

4. Grid operator sees list of available reserves per power plant1. Alternative: Operator filters the list by grid market area

5. Grid operator selects a reserve to regulate for spike

6. Grid operator enters power usage on the regulation1. Alternative: The system verifies that regulation is valid

7. Grid operator communicates the regulation to producer’s operation center using phone

1. Future: The system sends the regulation to the producer as XML/http

8. Balance is restored

9. At end of hour, system sends usage to pricing system (NOIS) (XML/http) via Sterling Integrator

10. Some time later, pricing system sends price for usage via SI

11. System sends price capacity usage to accounting system via SI

12. Accounting system pays producer for usage

Page 75: Bare-Bones Software Architecture

/Describe architecture

Page 76: Bare-Bones Software Architecture

What surprised you?

Your plan to change how you work?

What did you learn?

Page 77: Bare-Bones Software Architecture

Conclusion:

Page 78: Bare-Bones Software Architecture

Tomorrow: Make your system shine!

Page 79: Bare-Bones Software Architecture

Thank [email protected]

http://johannesbrodwall.com

http://exilesoft.com

http://twitter.com/jhannes

• Vision• Stakeholders• Usage flows

Page 80: Bare-Bones Software Architecture

• Lasagna architecture• Feature oriented architecture

• Deployment constraints

Page 81: Bare-Bones Software Architecture

Lasagna architecture

Page 82: Bare-Bones Software Architecture

Person-Controller

Person-Controller-

Impl

Person-Service

Person-ServiceImpl

Person-Repository

Person-Repository

Impl

PersonDao

PersonDaoImpl

Session-Factory

Page 83: Bare-Bones Software Architecture

Controllers

Services

Managers

Workers

Repositories

Page 84: Bare-Bones Software Architecture

Controllers

Services

Managers

Workers

Repositories

DTO

Domain

Mapping

Page 85: Bare-Bones Software Architecture
Page 86: Bare-Bones Software Architecture

Customer

Invoice

Order

Product

Page 87: Bare-Bones Software Architecture

Tidying up art (Ursus Wehrli)

Page 88: Bare-Bones Software Architecture
Page 89: Bare-Bones Software Architecture

Feature oriented architecture

Page 90: Bare-Bones Software Architecture
Page 91: Bare-Bones Software Architecture

Coherence• What changes together

lives together

Page 92: Bare-Bones Software Architecture
Page 93: Bare-Bones Software Architecture

Tolerance• What should be different

can be different

Page 94: Bare-Bones Software Architecture
Page 95: Bare-Bones Software Architecture

Meaning• What is central in domain

is central in code

Page 96: Bare-Bones Software Architecture
Page 97: Bare-Bones Software Architecture

Your thinking is contrained by

technology fashion:

Page 98: Bare-Bones Software Architecture

Controllers

Services

Managers

Workers

Repositories

DTO

Domain

Mapping

Page 99: Bare-Bones Software Architecture

Your solution is constrained by

deployment

Page 100: Bare-Bones Software Architecture

Web Application

Web user

Database

Browser

JSON/http

Web Service

SOAP

Web ServiceService

Consumer

DTO?

DTO

DTO

Controller

Page 101: Bare-Bones Software Architecture

Web Application

Web user

html/http

Database

Controller

DAO

Page 102: Bare-Bones Software Architecture

Web Application

Web user

html/http

Database

Reverse proxy

html/http

Controller

DAO

Page 103: Bare-Bones Software Architecture

Web Application

Web user

Database

Browser

JSON/http

DTO?Controller

DAO

Page 104: Bare-Bones Software Architecture

Web Application

Web user

Database

Rich client

Web service

DTO

DTO

Service

Consumer

Controller

Page 105: Bare-Bones Software Architecture

Web Application

Web user

Database

Rich client

Objects over http

DTO

DTOController

Page 106: Bare-Bones Software Architecture

Web Application

Web user

Database

Browser

JSON/http

Web Service

SOAP

Service

Consumer

DTO?

DTO

DTO

External client

Controller

DAO

Page 107: Bare-Bones Software Architecture

Web Application

Web user

Database

Browser

JSON/http

Service

External client

DTOController

DAO