Ju mer jag jobbar med arkitektur desto mer inser jag att det intressanta finns i det som tas för givet. Mitt lightning talk på Open Space 2010 handlade om detta. Om defaultarkitektur. Om det där som bara... Skall vara. Som t.ex.
- Identitet och säkerhet stavas LDAP - Det skall vara en flerskiktad modell - Vi MÅSTE ha en relationsdatabas annars går det åt...
Det roliga med modellen ovan är att jag jobbat med detta i över tio år och aldrig sett en bra implementation av en "Business Workflow" box enligt modellen. Har man tunga workflow så adresserar man det via en workflowmotor. Lätta workflows, enkla statemachines i domänmodellen. En annan intressant detalj är hur Business Components skiljer sig från Business Entities boxen. Det hela handlar givetvis mer om hur man vill modellera sin domän än om verb, substantiv och en artikel i msdn magazine som skall mappas till en box i en defaultmodell. Det intressanta är dock att det inte är helt ovanligt är att man sätter modellen ovan innan man överhuvudtaget gör en analys av den miljö man skall verka i.
De senaste åren har en ny defaultarkitektur etablerats, jag skall försöka rita den med en vy som kan mappas mot P&P modellen ovan, lite för mycket boxar för min smak, men det mappar renare mot vår första modell.
Det intressanta är att denna adresserar domäninterna och domänexterna frågor innan man låser skikt och liknande. Egentligen ser jag det hela på detta sätt:
Modellera aktuell domän ur ett verksamheltsperspektiv, id perspektiv, säkerhetsperspektiv och dataperspektiv innan ni bestämmer er för en arkitektonisk modell. Det går inte att utgå från en boxad defaultarkitektur och sedan försöka lista ut hur man skall trycka ner saker i aktuell box.
Hur var det nu Dreyfus studien uttryckte det...
Novice: rigid adherence to rules and no discretional judgment...
Och lösningen är ingen produkt eller teknologi... Hur gärna jag än vill att det skall vara det...