Principer för tjänstedesign


Nyttan med Tjänster är som störst när de återanvänds om och om igen. Detta är en av anledningarna till varför Webbtjänster (oftast SOAP/HTTP) är ett populärt sätt att implementera dessa Tjänster - det ger oss nåbarhet från många olika plattformar. Med nåbarheten kommer också möjligheten till återanvändning.

Allt för sällan finns det ett gemensamt register över tillgängliga tjänster. Men även om det skulle finnas ett register krävs det att man förhåller sig till ett antal principer för att hjälpa konsumenterna att hitta rätt tjänst och slutligen rätt operation(er) i detta register.

Jag har i denna artikel sammanställt de principer som jag anser är de viktigaste att anamma för att maximera återanvändningen av enskilda tjänster.

Namnge för konsumtion

Använd namn och begrepp som är bekanta för de som skall konsumera tjänsterna. Oftast är begrepp från den aktuella domänen mer meningsfulla för konsumenten än tekniska begrepp.

En tumregel kan också vara att använda substantiv till tjänstenamn och verb till operationsnamn.

public interface IManageMotorbikeData
{
    int InsertMotorbikeRecord();

    bool UpdateMotorbikeRecord();
}

Ovan: Tjänstedefinition som använder verb och IT-begrepp.

Nedan: Tjänstedefinition som använder substantiv och verb från verksamhetsdomänen.

public interface IMotorbikeService
{
    Motorbike CreateNewMotorbike();

    Parts UpgradeBikeWithCarbonParts(Motorbike motorbike);
}

Balansera antalet operationer per tjänst

Hitta en bra balans mellan antal tjänster och antal operationer per tjänst.

En tjänst blir ofta den enhet som testas och till slut släpps för konsumtion, vilket gör att tjänster med stort antal operationer kan påverka många konsumenter samt att de tar längre tid att testa och kvalitetssäkra. Har man istället många tjänster med få operationer per tjänst kan det bli svårare att hitta tjänsten med önskad operation.

Tjänsterna skall vara sammanhängande

Detta hänger till viss del ihop med föregående princip. Designa tjänsterna på så vis att dess operationer hör ihop. Vad som gör att de hänger ihop kan dock variera. Det kan t ex röra sig om;

  • Operationerna skall täcka de funktioner som behövs för att uppfylla ett scenario
  • Operationer som skall täcka de funktioner som kan utföras på en viss typ av entitet
  • En konsument har efterfrågat en tjänst med en specifik uppsättning operationer

Använd grovkorniga parametrar

Att definiera "grovkorniga" parametrar för en operation medför flera fördelar. För det första blir den enklare att använda. För det andra underlättare det kommande versionshantering av tjänstekontraktet då en förändring i datastrukturen inte behöver förändra signaturen på operationen.

int CreateNewMotorbike(string name, string brand, string color, double price);

Ovan: Finkorniga parametrar

Nedan: Grovkorniga parametrar

Motorbike CreateNewMotorbike(MotorbikeDetails newMotorbike);

Men tänk på..

När många i din organisation tycker att det fungerar kanon med Webbtjänster och vill ha mer och antalet konsumenter ökar - det är då problemen med konsumtion brukar uppenbara sig. Hur avvecklar vi en tjänst? Hur uppgraderar vi en tjänst från v1 till v2 utan att behöva uppdatera 20 konsumerande system? Rekommendationen är att samtidigt som du tar till dig ovan principer överväger att implementera ett virtualieringslager. Why Service Virtualization Matters är ett utmärkt whitepaper som introducerar dig till just detta.

Comments (1)

  1. Peter Bjorkmarker says:

    Antingen kan man ägna en dag åt att diskutera principer för hur man ska designa sina tjänster… eller (som jag gör nästa gång) kan man börja dagen med att läsa dina inlägg :). Bra skrivet, tack!

    Peter

Skip to main content