aega.Vene ajaloolane Ivan Golikov kirjutas selle kohta järgmist:"Monarh, olles nõuks võtnud tugevdada Tallinna kindlust ja teha seal uued sadamad. Peeter I ise tegi ka loetelu sellesinase töö jaoks kirvestest, kirkadest,labidatest ja kangidest."Tõsi kaubasadam oli Revelis igiammustest aegadest peale olemas. Ideaalseks oli aga niisugune kindlussadam, kus nii sõja- kui kaubalaevad paikneksid turvaliselt.Valmissaamiseni kulus mitu aastat.Säilinud on inseneeri Le Blondi plaan 10.veebruarist 1717, mis näitab ära sadama plaani täies mahus. Admiraliteedi kanali kaldale oli ehitatud sõjaväekasarmuid ja Admiraliteedi hooneid, läänemuuli otsa juurde rannale oli sadama kaitseks rajatud suurtükipatarei, ning täiendavad kaitserajatised Maarjamäel, Paljassaarel ja merre oli ehitatud ka kaitseks fort. Seeläbi muutus vainulike laevade sisenemine Tallinna lahte tülikaks. Vajades alalist peatuskohta, ostis ta 1714
Paindlik ja skaleeritav Taaskasutatav Kapseldatud ja sõltumatud osad Puudused: Keerukus Kommunikatsioon Siinipõhine arhitetkuur (ESB) Eelised: Kommunikatsioon Nõrgalt seotud komponendid Puudused: Single-point-of-failure Teenusepõhine arhitektuur (SOA) Eelised: autonoomne nõrgalt seotud jagatakse lepingut ja skeemi, mitte sisemisi klasse leitavus Erinevad platvormid Puudused tehniline keerukus, eriti WSDL-i ja SOAP-i puhul Arhitektuuri disain Ära üle inseneeri. Ära tee eeldusi, mida ei saa kontrollida. · Mis on fundamentaalsed osad arhitektuurist, mille valesti tegemine on väga suure riskiga süsteemile? · Milline osa süsteemist on suurima muutumise tõenäosusega? · Milliste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta? · Millised on võtme-eeldused ja kuidas neid kontrollida? · Mis võib põhjustada süsteemi ümber disainimise? ADD(Attribute Driven Design)
• Kasutaja volitused - kasutaja kogemus: ära dikteeri. Kasutajad muutuvad ebaõnnelikuks, kui peaks tegema midagi nende loogikaga vastuolas. • Turu küpsus - kasuta valmis komponente, ära leiuta jalgratast. Alati tasub otsida, äkki on keegi midagi sarnast teinud. • Paidlik disain - taaskasutatavus, hallatavus, skaleeritavus(pole odav). Tuleviku trendid mõjutavad alati arhitektuuri. Mõned tarkused: Ära üle inseneeri. Ära tee eeldusi, mida ei saa kontrollida. Tee täpselt seda, mida peab tegema. Kunagi ei tuleks eelduda, vaid tuleks kohe fakte kontrollida. Mõelda võiks: • Mis on fundamentaalsed osad arhitektuurist, mille valesti tegemine on väga suure riskiga süsteemi toimimisele. Alati on olemas mingi rakenduse osa, mille ümbertegemine on väga kallis. Tuleks olema valmis selleks, kui mingi häda tuleb.
● Turu küpsus kasuta valmis komponente, ära leiuta jalgratast ● Paidlik disain taaskasutatavus, hallatavus, skaleeritavus ● Tuleviku trendid Ei ole olemas universaalset arhitektuuri mustrit, mida valida. Kõik sõltub kliendist, süsteemist jmt. 45 101. Arhitektuuri disain. ! Ära üle inseneeri. Ära tee eeldusi, mida ei saa kontrollida. Disainimisel küsi kliendi käest nt päringute arvu, klientide arvu prognoosi jmt. Pole mõtet eeldada, et tuleb miljon klienti korraga, kui Eesti turg on selleks liiga väike ja seda kunagi ei juhtu. Disainimisel mõtle järgmistele asjadele: ● Mis on fundamentaalsed osad arhitektuurist, mille valesti tegemine on väga suure riskiga süsteemi toimimisele