Search code examples
javarestdomain-driven-designrepresentation

DDD: naming convention for Representation Layer and Domain Layer classes

I apologize in advance because this question is almost a bit silly. Nonetheless, I can't come up with a good solution myself, so I thought it still worthwhile to ask.

What does one do when the Representation object and the Domain object should have the same name? The DDD Sample doesn't really address the representation layer, so I was unable to find help there. An Account class works as well as any to illustrate:

package com.mycompany.myproduct.representation;

public class Account {
    private String uuid;
    private String accountNumber;
    // etc

    @JsonCreator
    public Account(@JsonProperty('uuid) String ....
}

Maybe this system has a convention to return data as a String whenever possible. But I like having all the Json annotations here. While that means XML isn't really supported, that seems okay for now, though more flexibility there would be nice. Then in the Domain layer there might be another class like this:

package com.mycompany.myproduct.domain.model;

import java.uti.UUID;

public class Account extends Entity {
    private UUID id;
    private BigDecimal accountNumber;
    // ... business logic, etc
}

If both of these datatypes are named the same the code will be ugly/unsupportable in the cases where they eventually have to meet. As part of the Ubiquitous Language, it seems like the Domain Layer HAS to have the Account Class. But the outside world talks in terms of the representation object. If that is their language, why should they use anything different?

Solution

  • Since these two classes are in separate namespaces, you could keep to the same name. But as you mentioned, this can get ugly and is certainly misleading.

    I strongly advocate for pure, "real-world" naming in your domain layer. Account is a great example. Your rich Account domain entity, with its state, behaviour and invariants, represents an account in the real world.

    Identifier naming outside of your domain should perhaps be more explicit to the context in which it is used. For example, I generally use the following:

    • AccountModel for an API response model.
    • AccountTable for a ORM class.
    • AccountDto for some transfer object (although please do try avoid DTOs!)

    Everyone has their own standard. I believe the important thing to be consistency, especially when you are working with a team.