armadilhas de design de domínio ORM

Domínios que possuem entidades onde o número de atributos (propriedades, parâmetros) que podem ser usados para descrevê-los é potencialmente vasto, mas o número que realmente se aplicará a uma determinada entidade é relativamente modesto.

Um exemplo de tal domínio seria uma prática médica, onde há um grande número de possíveis sintomas, mas o número de sintomas que qualquer paciente pode ter em qualquer momento é comparativamente pequeno.

Esses tipos de domínios são geralmente representados usando um modelo EAV (Valor de Atributo de Entidade) . Essa representação de dados é análoga a métodos eficientes de armazenamento de uma matriz esparsa, em que apenas valores não vazios são armazenados.

No caso de um domínio médico, o espaço do problema é complicado pelo fato de que qualquer sintoma ou teste médico pode ter seu próprio conjunto de atributos personalizados, assim como os produtos vendidos em uma loja online podem ter especificações personalizadas.

Na verdade, as lojas online também precisam lidar com esse problema. Um livro tem uma especificação de "número de páginas", enquanto um módulo de memória tem uma especificação de "número de bytes" e os dois atributos não estão relacionados.

Assim, um conjunto de atributos apropriados para cada produto é escolhido em uma tabela de atributos.

A tabela Atributos pode ter esta aparência:

AttributeID
AttributeDescription
UnitsID --> FK to Units table

A tabela ProductAttributes pode ter esta aparência:

ProductAttributeID
ProductID
AttributeID --> FK to Attributes table
Value

Observe que Número de bytes e Número de páginas não são recursos do esquema do banco de dados. Em vez disso, eles são codificados nas tabelas. Portanto, não há como representar esses recursos como parte do design do domínio.

Referenciando dados que podem mudar, em um registro que não deveria.

Eu vi várias implementações que tinham algo como:

Order
    Id : int
    OrderDate : DateTime

OrderProduct
    Id : int
    OrderId : FK of Order
    ProductId : FK of Product
    Quantity : int
    Cost : Decimal

Product
    Id : int
    Description : string

O código acaba parecendo algo como:

class Order
{
    int Id;
    DateTime OrderDate;
    List<OrderProduct> OrderLines;

    AddProduct(Product p, int quantity)
    {
        this.OrderLines.Add(new OrderProduct(this, p, q));
    }
}

class OrderProduct
{
    int Id;
    Product Product;
    Order Order;
    int Quantity;
    Decimal Cost;

    OrderProduct(Order o, Product p, int quantity)
    {
        this.Order = o;
        this.Product = p;
        this.Quantity = q;
        this.Cost = p.Cost * quantity * applicableTax;
    }
}

class Product
{
    int Id;
    string Description;
}

Parece correto à primeira vista, o código funciona bem, e os dados acabam sendo normalizados, e você pode criar e ler pedidos corretamente.

Exceto que, se você vender um pedido hoje e receber informações de um fornecedor amanhã de que a descrição de algo no produto foi alterada, esses sistemas normalmente apenas atualizam o produto com a alteração. Agora, se você reproduzir essa ordem daqui a dois dias, o conteúdo do pedido será alterado e você não será mais sábio.

Existem algumas maneiras fáceis de resolver esse problema, mas já o vi várias vezes em graus variados de gravidade.