Ilus arhitektuur

Jeffrey Palermo pakkus hiljuti välja arhitektuuri, mida ta nimetab “Onion Architecture”. See ei ole küll nii naljakas nagu Francis Shanahan välja pakkus.

Nimed pildil räägivad enda eest ning seletusi selle kohta leiab järgmistest kannetest: 1. osa, 2. osa, 3. osa.

Siiski teen kiire ülevaate asjadest:

• Domain Model – see on ärimudel. Seal on määratud äriobjektid ning nende vahelised seosed.
• Domain Services – Koosneb äriteenustest. Peamiselt sisaldab liideseid. Siia alla tuleb enam jaolt andmehoidlate liidesed, mille reaalsed klassid asuvad infrastruktuuris. Lisaks võib julgelt sinna alla viia ärilise sisuga teenuseid näiteks DiscountService vms.
• Application Services – Siin peaksid olema igasugused rakenduse teenuste liidesed. Lihtsamateks näideteks oleksid logimise (seda võib ka teha AOP kasutades) ja autentimise teenus.
• UI – See on rakenduse visuaalne külg. (Arvatavasti võib käsurida piisavalt visuaalseks nimetada =D)
• Infrastructure – Infrastruktuuriga tegelevad objekti. Sinna peaksid tekkima hoidlate (Repository) reaalsed klassid ning need võivad seotud olla NHibernate-ga.
• Tests – Kõiksugused testid.

Kihtide vahelised seosed on suunaga tuuma poole. Seega Domain Model ei peaks midagi soovima Domain Service ega ka Application Service kihist.

Need liidesed, mis on rakenduse tuumas viiakse kokku reaalsete klassidega DI Container‘i abil. Sellise mudeliga ei tea tuum midagi infrastruktuurist (Infrastructure Ignorance), ja ärimudel ei tea, et teda salvestatakse (Persistence Ignorance). See tähendab, et klassid on siis nö POCO või POJO, mille üldine nimetus peaks olema POxO ehk Plain Old x Objects. Tulemus on kergemini uuestikasutatav kood.

Kuna ise olen jõudnud lähedase arhitektuurini, siis natuke lisaks mõtteid ka omalt poolt. Kui juhtub, et UI-sid on mitu ja need on erinevates projektides, siis seadistuse pidev kopeerimine (ja sünkroniseerimine) ei ole just kõige mõnusam tegevus. Seega arvan, et infrastruktuuri ja UI vahele võiks sobida Configuration pakett. Selle peamiseks mõtteks oleks hoida NHibernate mapping faile, DI Container‘i seadistust (saaks koodis teha, vähem XML-i), teiste infrastruktuuri seadistused ja ka config failide sektsioonid (juhul kui vaja).

Selle puhul tuleb arvestada ka sellega, et sealne kood peaks olema piisavalt paindlik, et UI poolt saadud seadistusega saaks muuta. Näiteks UI-s tuleb siduda DI Container‘i abiga mõned kontrollerid. Seda mõtet pole veel jõudnud katsetada, seega kui keegi leiab, et sellega võib suuremaid probleeme tekkida, siis andke teada.

Teine probleem, mis selle juures mulle ette tuleb on äriobjektide valideerimine. Nimelt atribuutide kasutamine Domain Model‘is tundub selle puhul väär, sest see seob koheselt infrastruktuuriga. XML failide kirjutamine oleks lahendus, kuid seda väga ei eelistaks. Eelmise idee välja pakkumisega oleks hea kasutada koodi ehk DSL-i.

Igal juhul olen avatud igasugustele ettepanekutele, kuidas sellist arhitektuuri võiks paremaks muuta ja kuidas esinevaid probleeme lahendada.