Domain scope in a domain layer

Question

In my domain layer, I have a class called "Client". Normally, I would create properties directly related to this client in the class, for example, "First Name", "Last Name", "Address", etc., As well as methods related to the client.

My question is, will it be a bad OO design to add a method to this class that does work with a collection of clients?

eg. - let's say that there is an operation that I want to perform on the Client, for example, updating my email address. Before I do this, I want to make sure that there are no other clients with the same email address, so I am creating a method from the Client class called ValidateEmail (line emailAddress).

Inside this method, the Clients repository is requested for any existing client with this email address and returns a boolean value.

Would this be considered a poor OO design? I would prefer not to create any other classes or fill in the logic of the UI controller level with this check and it seems to match the Client class, but it seems that performing operations with siblings is not entirely correct.

thanks

Answer 1

If it were me, I would have a ClientCollection class. To a large extent, this is all the same to you, except for the name, so I see nothing in common with this.

Within this class, I can have a GetClientsWithEmail method that returns a list of clients with a specific email address. Thus, this method is just a search, does not contain any business logic. In fact, I could provide one linq line in it.

When someone tries to update the Client's email address, you will have some verification code. This may or may not be part of the Client class (you indicate that it is, but it is optional). In any case, this verification code can call the ClientCollection.GetClientsWithEmail method and verify that the returned number of Client objects is zero.