Clean architecture with C#: A better design to perform validation in Value Objects

Question

I'm creating an application which's architecture is based on Uncle Bob's Clean Architecture concepts and DDD. Note that it is BASED on DDD, so I gave myself the freedom to differ from strict DDD.

To create this application, I am using C# with .Net Standard 2.0

One of the principles of DDD relates to Value Objects. The definition for Value Objects, according to Wikipedia is as follows:

Value Object

An object that contains attributes but has no conceptual identity. They should be treated as immutable.

Example: When people exchange business cards, they generally do not distinguish between each unique card; they only are concerned about the information printed on the card. In this context, business cards are value object

Now, I want that my Value Objects does not allow their creation if some validation does not succeed. When it happens, an exception would be thrown during the instantiation. I really meant to throw an exception there, because the core of the architecture really does not expect any invalid data to reach that point.

Before going further on this question, to give you guys some more background, here is my architecture (NOTE: still incomplete):

The rules I am following in this architecture is:

1. A layer can only know about its immediate innermost neighbor layer's interfaces
2. A layer cannot know anything about any outermost layer
3. All communications between layers MUST be done through interfaces
4. Each layer must be independently deployable
5. Each layer must be independently developable

To better understand the arrows in this diagram, I recommend reading those Stack Exchanges's questions:

Explanation of the UML arrows

https://softwareengineering.stackexchange.com/questions/61376/aggregation-vs-composition

Now, the challenge I'm facing right now, is finding a good way to use the validators. I'm not satisfied with my architecture in this point. The problem is the following:

Since I can have thousands of Value Objects being instantiated at a given time, I don't want each instance of the Value Objects to have an instance method to perform the validation. I want the validation method to be static, since it's logic will be the same for every instance. Also, I want the validation logic to be available for the upper layer of the architecture to use to perform validations without trying to instantiating the Value Objects, thus causing an expensive exception to be thrown.

The problem is: C# DOES NOT ALLOW polymorphism with static methods, so I can't do something like:

internal interface IValueObject<T>
{
    T Value { get; }
    static bool IsValid(T value);
}

How can I achieve this functionality without relying on static methods polymorphism and, at the same time, not wasting memory?

Answer 1

It's a good thing that you can think abstractly but you should generalize after you write some working code.

A general clean on-size-fit-all architecture DDD is a Mith. In fact DDD applies only to the Domain layer. That's the beauty of it, it's technology agnostic.

In my projects I don't even have a base class or an interface for Value objects, Entities or Aggregate roots. I don't need them. All the these building blocks are POPO (PHP).

In my opinion, a Clean architecture is the one that keeps the Domain layer technology agnostic, without dependencies to any external frameworks. The other layers could be almost anything.

Answer 2

I suggest you get rid of IsValid() and make your Value Objects self-checking, always valid objects. Making them immutable is recommended and will obviously help a lot in that regard. You only have to check the invariants once during creation.

[Edit]

You might need to treat that as a first pass of input validation instead of value object invariant enforcement. If there's a huge amount of unsafe data coming in that you want to turn into value objects, first handle it in a validation process in the outer layer - you can make all performance optimizations you need, implement error logic and coordinate VO creation there.

Answer 3

In clean architecture all business logic goes into use case interactors. Validation rules are part of the business logic so should go into use case interactors as well.

In ur case I would suggest to put ur validation in interactors which take a "request model", validate the "parameters" and then return the respective value object(s) as (part of the) response model.

This way the validation logic is in the right layer and value objects are only created when validation succeeds - so no invalid value objects are created and no performance is wasted.