JavaScript Module Entity Patterns: En djupdykning i domänobjektmodellering

I mjukvaruutvecklingens värld, särskilt inom det dynamiska och ständigt föränderliga JavaScript-ekosystemet, prioriterar vi ofta hastighet, ramverk och funktioner. Vi bygger komplexa användargränssnitt, ansluter till otaliga API:er och distribuerar applikationer i en svindlande takt. Men i denna brådska försummar vi ibland själva kärnan i vår applikation: affärsdomänen. Detta kan leda till vad som ofta kallas "Big Ball of Mud" – ett system där affärslogiken är utspridd, data är ostrukturerad och att göra en enkel förändring kan utlösa en kaskad av oförutsedda buggar.

Det är här Domänobjektmodellering kommer in. Det är praktiken att skapa en rik, uttrycksfull modell av problemområdet du arbetar i. Och i JavaScript är Module Entity Pattern ett kraftfullt, elegant och ramverksagnostiskt sätt att uppnå detta. Denna omfattande guide kommer att ta dig igenom teorin, praktiken och fördelarna med detta mönster, vilket ger dig möjlighet att bygga mer robusta, skalbara och underhållbara applikationer.

Vad är Domänobjektmodellering?

Innan vi dyker in i själva mönstret, låt oss klargöra våra termer. Det är avgörande att skilja detta koncept från webbläsarens Document Object Model (DOM).

• Domän: I mjukvara är 'domänen' det specifika ämnesområdet som användarens verksamhet tillhör. För en e-handelsapplikation inkluderar domänen begrepp som Produkter, Kunder, Beställningar och Betalningar. För en social medieplattform inkluderar det Användare, Inlägg, Kommentarer och Likes.
• Domänobjektmodellering: Detta är processen att skapa en mjukvarumodell som representerar enheterna, deras beteenden och deras relationer inom den affärsdomänen. Det handlar om att översätta verkliga koncept till kod.

En bra domänmodell är inte bara en samling databehållare. Det är en levande representation av dina affärsregler. Ett Order-objekt bör inte bara innehålla en lista över artiklar; det bör veta hur man beräknar summan, hur man lägger till en ny artikel och om den kan avbeställas. Denna inkapsling av data och beteende är nyckeln till att bygga en motståndskraftig applikationskärna.

Det vanliga problemet: Anarki i "Model"-lagret

I många JavaScript-applikationer, särskilt de som växer organiskt, är 'modell'-lagret ofta en eftertanke. Vi ser ofta detta anti-mönster:

            
// Någonstans i en API-kontroller eller tjänst...
async function createUser(req, res) {
  const { email, password, firstName, lastName } = req.body;

  // Affärslogik och validering är utspridd här
  if (!email || !email.includes('@')) {
    return res.status(400).send({ error: 'En giltig e-postadress krävs.' });
  }

  if (!password || password.length < 8) {
    return res.status(400).send({ error: 'Lösenordet måste vara minst 8 tecken.' });
  }

  const user = {
    email: email.toLowerCase(),
    password: await hashPassword(password), // Någon verktygsfunktion
    fullName: `${firstName} ${lastName}`, // Logik för härledda data är här
    createdAt: new Date()
  };

  // Nu, vad är `user`? Det är bara ett vanligt objekt.
  // Ingenting hindrar en annan utvecklare från att göra detta senare:
  // user.email = 'an-invalid-email';
  // user.password = 'short';

  await db.users.insert(user);
  res.status(201).send(user);
}

            

              
                Copy
              
            
          

Denna metod presenterar flera kritiska problem:

• Ingen enskild sanning: Reglerna för vad som utgör en giltig 'användare' definieras i denna enda styrenhet. Vad händer om en annan del av systemet behöver skapa en användare? Kopierar du och klistrar in logiken? Detta leder till inkonsekvens och buggar.
• Anemisk domänmodell: `user`-objektet är bara en 'dum' dataväska. Den har inget beteende och ingen självmedvetenhet. All logik som fungerar på den lever externt.
• Låg sammanhållning: Logiken för att skapa en användares fullständiga namn blandas med hantering av API-begäran/svar och lösenordshashning.
• Svårt att testa: För att testa användarskapande logik måste du mocka HTTP-förfrågningar och svar, databaser och hashfunktioner. Du kan inte bara testa 'user'-konceptet isolerat.
• Implicita kontrakt: Resten av applikationen måste bara 'anta' att alla objekt som representerar en användare har en viss form och att dess data är giltiga. Det finns inga garantier.

Lösningen: JavaScript Module Entity Pattern

Module Entity Pattern löser dessa problem genom att använda en standard JavaScript-modul (en fil) för att definiera allt om ett enda domänkoncept. Denna modul blir den definitiva sanningen för den enheten.

En Module Entity exponerar typiskt en fabrikfunktion. Denna funktion ansvarar för att skapa en giltig instans av enheten. Objektet den returnerar är inte bara data; det är ett rikt domänobjekt som inkapslar sina egna data, validering och affärslogik.

Nyckelfunktioner i en Module Entity

• Inkapsling: Den paketerar data och funktionerna som arbetar med dessa data tillsammans.
• Validering vid gränsen: Den säkerställer att det är omöjligt att skapa en ogiltig enhet. Den skyddar sitt eget tillstånd.
• Klart API: Den exponerar en ren, avsiktlig uppsättning funktioner (ett publikt API) för att interagera med enheten, samtidigt som den döljer interna implementeringsdetaljer.
• Oföränderlighet: Den producerar ofta oföränderliga eller skrivskyddade objekt för att förhindra oavsiktliga tillståndsändringar och säkerställa förutsägbart beteende.
• Portabilitet: Den har noll beroenden av ramverk (som Express, React) eller externa system (som databaser, API:er). Det är ren affärslogik.

Huvudkomponenter i en Module Entity

Låt oss bygga om vårt `User`-koncept med hjälp av detta mönster. Vi kommer att skapa en fil, `user.js` (eller `user.ts` för TypeScript-användare), och bygga den steg för steg.

1. Fabrikfunktionen: Din objektkonstruktor

Istället för klasser kommer vi att använda en fabrikfunktion (t.ex. `buildUser`). Fabriker erbjuder stor flexibilitet, undviker att brottas med `this`-nyckelordet och gör privata tillstånd och inkapsling mer naturliga i JavaScript.

Vårt mål är att skapa en funktion som tar rådata och returnerar ett välformat, pålitligt User-objekt.

            
// fil: /domain/user.js

export default function buildMakeUser() {
  // Denna inre funktion är den faktiska fabriken.
  // Den har åtkomst till eventuella beroenden som skickas till buildMakeUser, om det behövs.
  return function makeUser({
    id = generateId(), // Låt oss anta en funktion för att generera ett unikt ID
    firstName,
    lastName,
    email,
    passwordHash,
    createdAt = new Date()
  }) {
    // ... validering och logik kommer att gå hit ...

    const user = {
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => email,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt
    };

    // Använder Object.freeze för att göra objektet oföränderligt.
    return Object.freeze(user);
  }
}

            

              
                Copy
              
            
          

Lägg märke till några saker här. Vi använder en funktion som returnerar en funktion (en högre ordningens funktion). Detta är ett kraftfullt mönster för att injicera beroenden, som en unik ID-generator eller ett valideringsbibliotek, utan att koppla enheten till en specifik implementering. För tillfället håller vi det enkelt.

2. Datavalidering: Väktaren vid porten

En enhet måste skydda sin egen integritet. Det bör vara omöjligt att skapa en `User` i ett ogiltigt tillstånd. Vi lägger till validering direkt inuti fabrikfunktionen. Om data är ogiltiga bör fabriken kasta ett felmeddelande och tydligt ange vad som är fel.

            
// fil: /domain/user.js

export default function buildMakeUser({ Id, isValidEmail, hashPassword }) {
  return function makeUser({
    id = Id.makeId(),
    firstName,
    lastName,
    email,
    password, // Vi tar nu ett vanligt lösenord och hanterar det inuti
    createdAt = new Date()
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Användaren måste ha ett giltigt ID.');
    }
    if (!firstName || firstName.length < 2) {
      throw new Error('Förnamnet måste vara minst 2 tecken långt.');
    }
    if (!lastName || lastName.length < 2) {
      throw new Error('Efternamnet måste vara minst 2 tecken långt.');
    }
    if (!email || !isValidEmail(email)) {
      throw new Error('Användaren måste ha en giltig e-postadress.');
    }
    if (!password || password.length < 8) {
      throw new Error('Lösenordet måste vara minst 8 tecken långt.');
    }

    // Datormalisering och transformation sker här
    const passwordHash = hashPassword(password); 
    const normalizedEmail = email.toLowerCase();

    return Object.freeze({
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => normalizedEmail,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt
    });
  }
}

            

              
                Copy
              
            
          

Nu måste alla delar av vårt system som vill skapa en `User` gå igenom denna fabrik. Vi får garanterad validering varje gång. Vi har också inkapslat logiken för att hasha lösenordet och normalisera e-postadressen. Resten av applikationen behöver inte veta eller bry sig om dessa detaljer.

3. Affärslogik: Inkapsla beteende

Vårt `User`-objekt är fortfarande lite anemiskt. Det innehåller data, men det *gör* ingenting. Låt oss lägga till beteende – metoder som representerar domänspecifika åtgärder.

            
// ... inuti makeUser-funktionen ...

    if (!password || password.length < 8) {
      // ...
    }

    const passwordHash = hashPassword(password);
    const normalizedEmail = email.toLowerCase();

    return Object.freeze({
      getId: () => id,
      getFirstName: () => firstName,
      getLastName: () => lastName,
      getEmail: () => normalizedEmail,
      getPasswordHash: () => passwordHash,
      getCreatedAt: () => createdAt,

      // Affärslogik / Beteende
      getFullName: () => `${firstName} ${lastName}`,
      
      // En metod som beskriver en affärsregel
      canVote: () => {
          // I vissa länder är rösträttsåldern 18 år. Detta är en affärsregel.
          // Låt oss anta att vi har en egenskap för födelsedatum.
          const age = calculateAge(dateOfBirth);
          return age >= 18;
      }
    });
// ...

            

              
                Copy
              
            
          

Logiken för `getFullName` är inte längre utspridd i någon slumpmässig styrenhet; den tillhör `User`-enheten själv. Alla med ett `User`-objekt kan nu på ett tillförlitligt sätt få det fullständiga namnet genom att anropa `user.getFullName()`. Logiken definieras en gång, på ett ställe.

Bygga ett praktiskt exempel: Ett enkelt e-handelssystem

Låt oss tillämpa detta mönster på en mer sammankopplad domän. Vi kommer att modellera en `Product`, en `OrderItem` och en `Order`.

1. Modellering av `Product`-enheten

En produkt har ett namn, ett pris och lite lagerinformation. Den måste ha ett namn, och dess pris får inte vara negativt.

            
// fil: /domain/product.js

export default function buildMakeProduct({ Id }) {
  return function makeProduct({
    id = Id.makeId(),
    name,
    description,
    price,
    stock = 0
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Produkten måste ha ett giltigt ID.');
    }
    if (!name || name.trim().length < 2) {
      throw new Error('Produktnamnet måste vara minst 2 tecken.');
    }
    if (isNaN(price) || price <= 0) {
      throw new Error('Produkten måste ha ett pris som är större än noll.');
    }
    if (isNaN(stock) || stock < 0) {
      throw new Error('Lagret måste vara ett icke-negativt tal.');
    }

    return Object.freeze({
      getId: () => id,
      getName: () => name,
      getDescription: () => description,
      getPrice: () => price,
      getStock: () => stock,
      
      // Affärslogik
      isAvailable: () => stock > 0,
      
      // En metod som ändrar tillståndet genom att returnera en ny instans
      reduceStock: (amount) => {
        if (amount > stock) {
          throw new Error('Inte tillräckligt med lager tillgängligt.');
        }
        // Returnera ett NYTT produktobjekt med det uppdaterade lagret
        return makeProduct({ id, name, description, price, stock: stock - amount });
      }
    });
  }
}

            

              
                Copy
              
            
          

Notera metoden `reduceStock`. Detta är ett avgörande koncept relaterat till oföränderlighet. Istället för att ändra egenskapen `stock` på det befintliga objektet, returnerar den en *ny* `Product`-instans med det uppdaterade värdet. Detta gör tillståndsändringar explicita och förutsägbara.

2. Modellering av `Order`-enheten (Roten för Aggregatet)

En `Order` är mer komplex. Det är vad Domain-Driven Design (DDD) kallar en "Aggregate Root." Det är en enhet som hanterar andra, mindre objekt inom sin gräns. En `Order` innehåller en lista över `OrderItem`s. Du lägger inte till en produkt direkt i en order; du lägger till en `OrderItem` som innehåller en produkt och en kvantitet.

            
// fil: /domain/order.js

export const ORDER_STATUS = {
  PENDING: 'PENDING',
  PAID: 'PAID',
  SHIPPED: 'SHIPPED',
  CANCELLED: 'CANCELLED'
};

export default function buildMakeOrder({ Id, validateOrderItem }) {
  return function makeOrder({
    id = Id.makeId(),
    customerId,
    items = [],
    status = ORDER_STATUS.PENDING,
    createdAt = new Date()
  }) {
    if (!Id.isValidId(id)) {
      throw new Error('Ordern måste ha ett giltigt ID.');
    }
    if (!customerId) {
      throw new Error('Ordern måste ha ett kund-ID.');
    }

    let orderItems = [...items]; // Skapa en privat kopia att hantera

    return Object.freeze({
      getId: () => id,
      getCustomerId: () => customerId,
      getItems: () => [...orderItems], // Returnera en kopia för att förhindra extern modifiering
      getStatus: () => status,
      getCreatedAt: () => createdAt,
      
      // Affärslogik
      calculateTotal: () => {
        return orderItems.reduce((total, item) => {
          return total + (item.getPrice() * item.getQuantity());
        }, 0);
      },

      addItem: (item) => {
        // validateOrderItem är en funktion som säkerställer att artikeln är en giltig OrderItem-enhet
        validateOrderItem(item);

        // Affärsregel: förhindra att dubbletter läggs till, öka bara kvantiteten
        const existingItemIndex = orderItems.findIndex(i => i.getProductId() === item.getProductId());

        if (existingItemIndex > -1) {
          const newQuantity = orderItems[existingItemIndex].getQuantity() + item.getQuantity();
          // Här skulle du uppdatera kvantiteten på den befintliga artikeln
          // (Detta kräver att artiklarna är muterbara eller har en uppdateringsmetod)
        } else {
          orderItems.push(item);
        }
      },

      markPaid: () => {
        if (status !== ORDER_STATUS.PENDING) {
          throw new Error('Endast väntande order kan markeras som betalda.');
        }
        // Returnera en ny Order-instans med den uppdaterade statusen
        return makeOrder({ id, customerId, items: orderItems, status: ORDER_STATUS.PAID, createdAt });
      }
    });
  }
}

            

              
                Copy
              
            
          

Denna `Order`-enhet upprätthåller nu komplexa affärsregler:

• Den hanterar sin egen lista över artiklar.
• Den vet hur man beräknar sin egen summa.
• Den upprätthåller tillståndsövergångar (t.ex. kan du bara markera en `PENDING`-order som `PAID`).

Affärslogiken för order är nu snyggt inkapslad i denna modul, testbar isolerat och återanvändbar i hela din applikation.

Avancerade mönster och överväganden

Oföränderlighet: Hörnstenen för förutsägbarhet

Vi har berört oföränderlighet. Varför är det så viktigt? När objekt är oföränderliga kan du skicka dem runt i din applikation utan rädsla för att någon avlägsen funktion ska ändra deras tillstånd oväntat. Detta eliminerar en hel klass av buggar och gör din applikations dataflöde mycket lättare att resonera om.

Object.freeze() tillhandahåller en ytlig frysning. För enheter med kapslade objekt eller arrayer (som vår `Order`) måste du vara mer försiktig. Till exempel, i `order.getItems()`, returnerade vi en kopia (`[...orderItems]`) för att förhindra att anroparen trycker in artiklar direkt i orderns interna array.

För komplexa applikationer kan bibliotek som Immer göra det mycket enklare att arbeta med oföränderliga kapslade strukturer, men grundprincipen kvarstår: behandla dina enheter som oföränderliga värden. När en förändring behöver ske, skapa ett nytt värde.

Hantering av asynkrona operationer och persistens

Du kanske har märkt att våra enheter är helt synkrona. De vet ingenting om databaser eller API:er. Detta är avsiktligt och en stor styrka i mönstret!

Enheter ska inte spara sig själva. En enhets uppgift är att upprätthålla affärsregler. Uppgiften att spara data i en databas tillhör ett annat lager i din applikation, ofta kallat ett Service Layer, Use Case Layer eller Repository Pattern.

Så här interagerar de:

            
// fil: /use-cases/create-user.js

// Detta användningsfall är beroende av fabrikfunktionen för användarenheten och en databasåtkomstfunktion.
export default function makeCreateUser({ makeUser, usersDatabase }) {
  return async function createUser(userInfo) {
    // 1. Skapa en giltig domänenhet. Detta steg validerar data.
    const user = makeUser(userInfo);

    // 2. Kontrollera efter affärsregler som kräver externa data (t.ex. e-postadressens unikhet)
    const exists = await usersDatabase.findByEmail({ email: user.getEmail() });
    if (exists) {
      throw new Error('E-postadressen används redan.');
    }

    // 3. Behåll enheten. Databasen behöver ett vanligt objekt.
    const persisted = await usersDatabase.insert({
      id: user.getId(),
      firstName: user.getFirstName(),
      // ... och så vidare
    });

    return persisted;
  }
}

            

              
                Copy
              
            
          

Denna ansvarsfördelning är kraftfull:

• `User`-enheten är ren, synkron och lätt att enhetstesta.
• Användningsfallet `createUser` ansvarar för orkestrering och kan integrationstestas med en mockdatabas.
• Modulen `usersDatabase` ansvarar för den specifika databastekniken och kan testas separat.

Serialisering och deserialisering

Dina enheter, med sina metoder, är rika objekt. Men när du skickar data över ett nätverk (t.ex. i ett JSON API-svar) eller lagrar det i en databas, behöver du en vanlig datarepresentation. Denna process kallas serialisering.

Ett vanligt mönster är att lägga till en `toJSON()` eller `toObject()`-metod till din enhet.

            
// ... inuti makeUser-funktionen ...

    return Object.freeze({
      getId: () => id,
      // ... andra getters

      // Serialiseringsmetod
      toObject: () => ({
        id,
        firstName,
        lastName,
        email: normalizedEmail,
        createdAt
        // Observera att vi inte inkluderar passwordHash
      })
    });

            

              
                Copy
              
            
          

Den omvända processen, att ta vanliga data från en databas eller API och förvandla det tillbaka till en rik domänenhet, är exakt vad din `makeUser`-fabrikfunktion är till för. Detta är deserialisering.

Typning med TypeScript eller JSDoc

Medan detta mönster fungerar perfekt i vanlig JavaScript, ger du det superkraft genom att lägga till statiska typer med TypeScript eller JSDoc. Typer gör att du formellt kan definiera 'formen' på din enhet, vilket ger utmärkt automatisk komplettering och kontroller vid kompilering.

            
// fil: /domain/user.ts

// Definiera enhetens publika gränssnitt
export type User = Readonly<{
  getId: () => string;
  getFirstName: () => string;
  // ... etc
  getFullName: () => string;
}>;

// Fabrikfunktionen returnerar nu User-typen
export default function buildMakeUser(...) {
  return function makeUser(...): User {
    // ... implementering
  }
}

            

              
                Copy
              
            
          

De övergripande fördelarna med Module Entity Pattern

Genom att anta detta mönster får du en mängd fördelar som växer när din applikation växer:

• Enskild sanning: Affärsregler och datavalidering är centraliserade och entydiga. En förändring av en regel görs på exakt ett ställe.
• Hög sammanhållning, låg koppling: Enheter är självständiga och beror inte på externa system. Detta gör din kodbas modulär och lätt att refaktorera.
• Överlägsen testbarhet: Du kan skriva enkla, snabba enhetstester för din mest kritiska affärslogik utan att mocka hela världen.
• Förbättrad utvecklarupplevelse: När en utvecklare behöver arbeta med en `User` har de ett tydligt, förutsägbart och själv-dokumenterande API att använda. Inget mer gissande om formen på vanliga objekt.
• En grund för skalbarhet: Detta mönster ger dig en stabil, pålitlig kärna. När du lägger till fler funktioner, ramverk eller användargränssnittskomponenter, förblir din affärslogik skyddad och konsekvent.

Slutsats: Bygg en solid kärna för din applikation

I en värld av snabbrörliga ramverk och bibliotek är det lätt att glömma att dessa verktyg är övergående. De kommer att förändras. Det som består är kärnlogiken i din affärsdomän. Att investera tid i att ordentligt modellera denna domän är inte bara en akademisk övning; det är en av de mest betydande långsiktiga investeringar du kan göra i hälsan och livslängden för din mjukvara.

JavaScript Module Entity Pattern ger ett enkelt, kraftfullt och inbyggt sätt att implementera dessa idéer. Det kräver inget tungt ramverk eller en komplex installation. Det utnyttjar språkets grundläggande funktioner – moduler, funktioner och stängningar – för att hjälpa dig att bygga en ren, motståndskraftig och förståelig kärna för din applikation. Börja med en nyckelenhet i ditt nästa projekt. Modellera dess egenskaper, validera dess skapande och ge den beteende. Du kommer att ta det första steget mot en mer robust och professionell mjukvaruarkitektur.