DDD：如何从Kotlin中的集成层隐藏特定的聚合根构造函数

Question

I'm kinda new on DDD and even after read the blue and red book I still have some questions about how to transform some principles to code, specifically using Kotlin and Java.

For example, I identify a Client aggregate root that receive some parameters need it for the creation like Name and Address:

class Client: AggregateRoot {

    var clientId: ClienteId
    var name: Name
    var address: Address

    constructor(name: Name,address: Address) : super(){
        // validations ....
        this.name = name
        this.address = address
    }

Easy part: To create a new Client I receive a DTO inside the RS service and try to create a new Client class passing the parameters above, case everything was solid and all rules fulfilled I send the new instance of Client to the repository, pretty straight foward.

clientRepository.store(client)

Other part: I need to search my Client to change the address so I send the id to the repository and find the Client inside the database then I need to convert the database entity to the aggregate root and return to the caller.

override fun getById(id: Long): Client {
  val clientEntity = em.find(...)
  val client: Client(.....) //But I need another constructor with ClientId
  return client
}

Then I will need a new constructor one that receive more parameters like the ClientId

constructor(clientId: ClienteId,name: Name,address: Address) : super(){

The problem is that every service can call this new constructor and create a incorrect instance of my aggregation root, so my questions are:

1. Is there a way to hide the complete constructor just for the repository or specific layers to see. Like in C# when you could use internal.
2. Is there any solution for Java or Kotlin to not expose this constructor that should be used just on tests and integrations ?

Another example is if I didn't need the address to be passed every time a client is created but just after in another method like:

client.addAddress(address)

But in both cases I will need to fulfill the entire Client from the database so I will need a second constructor with the address parameter.

Answer 1

So, the problem is how to rehydrate an Aggregate from the persistence without breaking its encapsulation by exposing the wrong interface to the client code (ie the Application layer or the Presentation layer).

I see two solutions to this:

1. Use reflection to populate the fields. This is the solution that most ORMs use and it is also the most generic. It works for most persistence types, even when there is an impedance mismatch. Some ORMs need to annotate fields or relations.

2. Expose a different interface to the client code. This means that your Aggregate implementation is larger that the interface and contains additional initialization methods used only by the infrastructure.

As an example in pseudo-code your could have:

// what you want the upper layers to see
interface Client {
    void addAddress(address);
}

// the actual implementations
public class ClientAggregate implements Client 
{
    void rehidrate(clientId,name,address){...}
    void addAddress(address){...}
}

public class ClientRepository
{
    // this method returns Client (interface)
    Client getById(id){
        val clientEntity = em.find(...)
        val client = new ClientAggregate()
        client.rehydrate(clientEntity.id, clientEntity.name, clientEntity.address)
        return client //you are returning ClientAggregate but the other see only Client (interface)
    }
}

As a side note, I don't expose the constructor to create an Aggregate from the Domain point of view. I like to have empty constructors and a dedicated method, named from the Ubiquitous language , that creates the Aggregate. The reason is that is not clear that the constructor creates a new Aggregate. The constructor instantiate a new instance of a class; it is more a implementation details than a domain concern. An example:

class Client {
    constructor(){ //some internal initializations, if needed }
    void register(name){ ... }
}