small is beautiful

small methodssmall classessmall team

small companysmall away day :-)

big problemscomplex world

lot of talentbig aspirations

but....

e.g., can a small company solve big problems?

lets leave that for the bar

we care about beautifulsmall is means

why we like small in software

simpler to understand

easier to change

faster to get our work done

we like making progress

small in software development

small methodssmall classes

small modulessmall applications

small teams

small methods

tell don't askextract method refactoring

strategy pattern....

extract method

when to stop?extract only when it adds beauty

avoid compression

when to stop, when is if-else betterwhen strategy is not a domain concept

simplicity > small

strategy pattern

small classes

extract class refactoring

http://www.refactoring.com/catalog/extractClass.html

can be applied to a primitive, collection or domain primitive

number --> money --> salary

language primitivedomain primitive

value object

smaller modules

module by responsibility types

repositoriesdomainservicescontractsmappers

a service module

does this add beauty?

doesn't scaleover period of time everything still bloats

not much

Conceptually

modules by domain

reference dataorganization

customer, productaccounts

payments, cash flow, questionnaire

module layers (mifos)

weak links between modulescohesion within a module

identical rate of change of data

to find modules

hard to evolve todeliberately design and implement

for me..

consequences

module encapsulate complexity

only interact to module using its interface

provides decoupling

domain model externally in-visibleno cross module entity relationship

[hibernate]use identity

can still use foreign keys

encapsulated domain

inter module communication

to dependee module

ask

pass message (logical)

e.g. accounts to payments module, tellmakeEntries(amount, customerId)

instead pass messagepaymentMade(amount, customerId)

no assumption of implementation

to sibling module

use eventsproduct to account module

meetingScheduleChanged(productType)

with dependent module

cross cutting module

performancecross module operations

module not just to provide reusabilitybut to stay small

namespaces, for layers in a domain module

small applications

un-shared codeserving some utilityun-shared database

what is an application

don’t reinventbe lazy first look outside

simplest rule

deploymentusers

departmentasynchronous processes

contained workflowsloose coupling

how to carve applications

examples

public websitecall centerfulfillment

user and workflow driven

trainlines

outlooksanitization

managementsynchronization

user and workflow driven

bcg

unnoticed in insurecom

single ugly monolith (although….)

administrationaccounting

policy and claims…

insurecom

too small applicationsrackspace

same users, different applications, dealing with similar data

too fine breakup

rackspace

challengestest of the parition

joins across systems

e.g.show all unused IP address in this data

center

put databases on same serverselect … from location.datacenters,

network.ipblocks where ….

hack!

query one and query another with resultchange use case, what does user want

reporting from data warehouseis it happening quite frequently?

transaction across systems

distributed transaction

bad performanceavailability impact

idempotent operationsasynchronous updates

decentralized datais it happening quite frequently?

centralized data application

configuration data in rackspace

de-centralize your data

configuration data in rackspace

location configurationnetwork configuration

…..

explain principlesexplain application architecture

build common vocabularytake feedback

evolve

customer and analysts

small teams

20 members

developer team = 10qa team = 6

build & deployment team = 4

beautiful?

journey search & journey options

same locationno contracts

artificial user storiesdatabase based dependencysame continuous integration

beautiful?team by module

babies joined at hip

website and call center

different locationINVEST storiesloose coupling

different continuous integrationbusiness contracts

team by application

INVEST storiesown continuous integration

own releasedifferent location

application contracts

small team test

beware of conway's law

software provides archaeological evidence of people/team who worked on it

architecture and team organization are not independent

questions