Clean Code Architecture and Entity Validation

[witali mik]

Hello guys,

to learn the Clean Code Architecture i started a personal Project, now i wonder how to deal with data validation.

The Use Case input port, i called Request and Output Port i called it response in my code

Before cleancode, i used several Validation classes of Frameworks, now i did it other way.
My Entities validate the date, they accept.

For Example
https://github.com/Opentribes/Core/blob/develop/src/OpenTribes/Core/Player.php#L44

In some Use Cases, i require additional validations, like this:
https://github.com/Opentribes/Core/blob/develop/src/OpenTribes/Core/Player/Create/Interactor.php#L41

iam currently not sure, is this the right way? or should i create a validation interface and require it within my interactors?

hope someone can explain me it:D

[Sebastian Gozin]

I'm still split on this. I personally feel input validation is highly contextual to the usecase rather than an entity. Or put otherwise validating an entity is often wider than validating the diff we're trying to apply.
Does that even make sense?

[witali mik]

well but i think, it would be a bad way, to validate over and over the same properties in each interactor/use case. so for example lets say, someone have to change the minimum character lenght for username, so he has to do it in each usecase where the entity is will be used.. but this are just thoughts.. i just dont know the right way :D

[Sebastian Gozin]

Neither do I.

On character length for example. When we use twitter we can use a maximum of 140 characters for whatever reason. I could totally see Twitter allow more than 140 characters for people who pay a fee. Hence why I think validations can be contextual.
Perhaps an entity is a good place for validations which apply to all usecases but even then I sometimes end up ina  situation where I really wish I had not put that validation there because a new context popped up which requires it to be different.

[witali mik]

well 140 character reason is because of sending Tweets over SMS(a funny thing exists before Whatapp:D) one SMS contains exactly 140 characters, if you write an SMS from modern mobile phone to an old phone, more than 140 characters, the old phone will recive 2 SMS or more depends of amount of characters
back to topic:D...

Currently iam mixing a contextual and entity validation, thiswhy i need to create some strange stuffs like this

https://github.com/Opentribes/Core/blob/develop/src/OpenTribes/Core/Player/Login/Interactor.php#L29

i create an empty entity, put the request values insides, if there is no exception thrown, i go further with context validation like here

https://github.com/Opentribes/Core/blob/develop/src/OpenTribes/Core/Player/Login/Interactor.php#L40

and to allow someone modify the validations of the entity, i made even more strange stuffs

https://github.com/Opentribes/Core/blob/develop/features/bootstrap/UserHelper.php#L37

so an interactor is using Repositories to fetch entities and modify them. a Repository stores usually data but not entities it selfs( you have basicly table rows not complete objects in database) so you need to create them, therefore iam using a Factory Design pattern, to ensure that a required entity will be created by my EntityFactory i set the Object which the Factory should create..

i just want to know if this is a good way, or is it better, to create a Validation Interface which must be created for each interactor, since every interactor could have his custom validation rules..

[Sebastian Gozin]

Let's see if others chime in with opinions.

I certainly inject validation rules at the usecase level to deal with these contextual situations. In fact sometimes even the usecase is not contextual enough and I may select rules based on the active user, his permissions or other environmental facts.

[Andreas Schaefer]

In a blogpost form MarkSeemann (http://blog.ploeh.dk/2010/07/12/DomainObjectsandIDataErrorInfo/) he says "..Domain Objects should be designed so that they cannot be put into invalid states. They should guarantee their invariants." 

In a clean architecture this of course would regard only the enterprise wide concerns. All application specific validations would happen in interactors. If I'd have to validate the same application specific thing in more than one place I'd rather encapsulate this logic into a separate interactor that can be used by other interactors .. instead of not staying DRY by implementing an ValidationInterface.

Also a useful read: http://www.martinfowler.com/bliki/AnemicDomainModel.html  .. where Martin says: "The logic that should be in a domain object is domain logic - validations, calculations, business rules"

Regarding this article I see 'service layer' (application layer in DDD) the same as the interactors.

So an important thing to know is the difference between enterprise wide and application specific (validation) logic.

> a Repository stores usually data but not entities it selfs( you have basicly table rows not complete objects in database)

I'd say from a client point of view (interactor) using the repository, it does store entities! The client doesn't even know what the specific storage technique exactly is (in-memory, rdbms, noSql, graph etc.)

> ... so you need to create them, therefore iam using a Factory Design pattern, to ensure that a required entity will be created by my EntityFactory i set the Object which the Factory should create

You have to differentiate between e.g. storing an entity (via repository) and creating a new entity. For the creation of a new entity the factory pattern is often used. But the repository isn't involved in creating a new entity. I'd say it's a specific useCase/interactor that does this.

hope this helps,

 Andreas Schaefer

[Caio Fernando Bertoldi Paes de Andrade]

I think that an entity that validating itself is a violation of the SRP.

There should be one interactor whose responsibility is to make one change in the state of an entity. All interactors who want to perform that change should reuse (instantiate and call) the interactor created for that purpose.

This way you keep classes with only one responsibility and you DRY.

Remember that use cases can chain themselves, and that some interactors will belong to the core layer of your application, and they will be called mainly by other interactors (the ones that actually interact directly with the delivery mechanism).

If you see an interactor with too much knowledge, refactor it into others that know how to do only one thing.

Hope this helps to clarify,

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Caio Fernando Bertoldi Paes de Andrade]

Just to clarify my point:

The validation should happen in the interactor responsible for that change of state.

So you don’t repeat validation code in other interactors, and you keep entities clean.

Caio

[witali mik]

well currently iam confused.. i will read the blogs first then and try to understand, what they tryin to describe, thx for the links

Caio

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Uncle Bob]

Entities can have validation functions, but they should be application specific.  That means they are general validations that enforce invariants, and not specific validations for specific cases.  

Imagine a payroll system in which employees under the age of 18 must be hourly, but 18 and over can be salaried or commissioned as well.  The interactor that adds new employees accepts a request data structure that has specified hourly, salaried, or commissioned, as well as age.  Who is responsible for validating that the age and payment classification are appropriate?

Before we answer that, let's get one thing out of the way.  What happens at the GUI is irrelevant.  You might have some javascript that prevents ages under 18 from selecting anything but Hourly; but that is beside the point.  The validation still has to be done on the interactor side of the boundary because that side is not allowed to depend upon the GUI in any way.  

Should the age restriction be enforced by the employee entity, or by an sub-interactor called by the add-employee-interactor and the change-employee-interator?  This depends entirely on the volatility of the policy.  If this is an iron-clad policy that must be maintained by every application that uses the Employee entity, then by all means put it in that entity.  If, however, that policy is subject to change in such a way that different applications would use different policies. (e.g. different states or different countries) then it might be better to keep the validation in the interactors.  

Interactors are, by their nature, more volatile than entites.  The two kinds of objects change at different rates and for different reasons.  The validation should go in the object that has the most similar change rate.  So if the age/class restriction is volatile, and might change based on time, region, mangement style, or etc... then I'd put it in the interactors.  If, however, the age/class restriction is fundamental to the Employee entity, and won't change unless there is a foundational change to that entity, then it would be better to put the validation in the entity.

This is really just the SRP / CCP again. Gather together things that change for the same reasons.  Separate things that change for different reasons.

[Andreas Schaefer]

Thanks UncleBob for this detailed explanation of an example.

On Wednesday, September 11, 2013 5:28:43 PM UTC+2, Uncle Bob wrote:

Entities can have validation functions, but they should be application specific.

.. didn't you intend to say 'not' application specific in your first sentence?

[Caio Fernando Bertoldi Paes de Andrade]

Thanks for the clarification, Uncle Bob!

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[witali mik]

wow.. so all the things i did, were correct?(exept the factory method) now iam surprised

[Andreas Schaefer]

Aren't you suprised that Uncle Bobs first statement "Entities can have validation functions, but they should be _application_ specific" doesn't match the whole rest of his statements and examples ?

[Sebastian Gozin]

A simple case of forgetting to type "not" perhaps?

[Uncle Bob]

Yes, I omitted the negative modifier.

[daniphp]

Should the Interactors throw Exceptions if the validation fails?

[witali mik]

Yes of course. Currently iam using following Approach.

http://pastebin.com/DW80rGbB
so basicly i have a simple "validationObject" its just a plain object with public properties, the properties gets some values from entity itselfs or just any properties, so the validator just have this object to validate it.

like in the example, i just search for a user by username , if i did not find any, so the username is unique. my validator does not to know anything about repositories or entities, the validator just know the stuffs, which he needs to validate

[Łukasz Duda]

Hi,
I think there is no simple answer. It depends on the role of interactor.
If the interactor is designed to validate and then execute action or return validation error message, in my opinion it should not throw exception. Instead it should return messages in consistent manner.
On the other hand if the interactor assumes valid parameters by design (for example utility interactors), it can throw exception if they are not valid. Another interactor, which uses the utility interactor should then catch the exception and it could send appropriate message to the client.

From my experience I find that: The closer to application boundary, the less exceptions.
I don't want to send stack trace and other details to the application client.

[Jop van Raaij]

What about validating format? The user has to type a date in the user interface, but the Interactor only accepts a Calendar object as input. Now the Controller driving the Interactor has to verify if the date can be converted to a Calendar. And the Controller also has to provide error messages if applicable. Now I have validation logic outside my application. Also the logic like: when the user types x, stay on the same page and show error message y.

Or does this mean the Interactor should accept a date as string, try to convert it to a Calendar and handle parse exceptions by sending error messages back? Now the date parsing logic is inside the application.

[Caio Fernando Bertoldi Paes de Andrade]

Jop,

Let’s say we have a ScheduleMeetingInteractor.

Is really the responsibility of this interactor to validate if the user has input the right String format to be parsed into a Calendar?

What if we change the date format accepted? Should the interactor change?

Did any of the _business_ rules change? Or only a _presentation_ rule has changed?

Interactors (and Entities) should deal with business rules. An example would be that a meeting shouldn’t be scheduled if there is any overlap with another meeting. String formatting is a presentation rule, so the delivery mechanism should take care of this.

Now let’s say we have a RelativeStringCalendarParser. The user would input “tomorrow” and the Parser would parse that String into the appropriate Calendar instance.

Is really this parser part of the delivery mechanism?

Does it depend on the GUI at all? Or it represents some business value that is independent of the delivery mechanism?

I sounded very controversial here, but that was intentional. Of course the definition of "business rule" and "presentation rule” change from application to application. There is no right answer, only right questions you have to ask yourself based on your application’s domain.

My own personal take on this example: I would place the parser amongst the Interactors, and have a RelativeStringScheduleMeetingInteractor accept a String, call the parser and then pass the resulting Calendar to the real ScheduleMeetingInteractor, keeping both responsibilities separate, but not bound to the delivery mechanism.

Hope this helps,

Caio

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.

[Jop van Raaij]

Yes, that helps. Thanks!

I'm having a hard time defining the business rules and presentation rules. I do not agree on your own personal take however. The term 'tomorrow' is just another representation of tomorrows date and therefor part of the presentation, not the application. When multiple interfaces are using the 'tomorrow' representation there should be a location to share the conversion to an actual date somewhere, I agree. I would use a library used by the clients, or the application.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Łukasz Duda]

I don't validate format. I assume that all clients ensure valid format. If it's not the case and delivery mechanism cannot bind value, it throws exception, which is handled and the default error message is shown. It shouldn't happen if client was properly constructed.
For me it would be kind of defensive programming, which I try to avoid.

[Jop van Raaij]

I agree you should not use defensive programming. But only when talking about code I've written and data I'm passing around. When handling user input, you have to assume a 'bad' user (SQL injection, etc) and therefore do 'defensive' programming for that data.

Consider again the form with the date field. The following tests are input->output data mappings from the users perspective:
1. No date entered -> "please enter a date"
2. No valid date format used, like 1-2-3 -> "please enter a date in the format yyyy-mm-dd"
3. No valid date entered, like 30th of Februari -> "please enter a valid date"
4. Date in the past entered (where the application can only use dates in the future) -> "please enter a future date"

When handling 1. and 2., I would think it should be handled in the presentation layer (client).
When handling 3. and 4., I would use the application.

Now some validation is in the client en some of it is in the application. This feels clumsy. When looking at the tests in the application to see the intent of the application, I also think 'what happens when the users uses an invalid an invalid date format?'. There is no test in the application, because it should be handled by the client (presentation). This problem could be solved by using a Calendar object when passing the date format. But I probably should do a 'null' -> 'please provide a date' test in the application for the possibility of a null value for the Calendar. Assuming I always write the client myself and I'm never returning or calling a method with null, this test could be skipped. Trying to keep the presentation layer as simple as possible, I'd move as much of the validation to the application. But maybe that's not the best solution and it is OK to have part of the tests in the client and part of them in the application? After all, when passing in a Calendar object, I know for sure there is a valid date (format) inside.

[witali mik]

Well I'am not sure how that looks in other programming languages, but in PHP There is a DateTime class which can create a DateTime Object from format, if the format is not correct, there method returns false and you dont have a DateTime Object.

Ich i say, i require a DateTime Object, i get only the Object in correct format, else i just throw an error like, Wrong Input

[Łukasz Duda]

I'd put 1 and 4 into application (interactors). These are business rules - date is required and it must be a future date.
In my web applications I usually do 2 and 3 at client side. Binding data at controller will ensure that request parameters are valid and have matching types.
In desktop applications controlls (widgets) ensures valid input type. The interactor request data structures are strongly typed, and there is no possibility to put incorrectly formatted date string into date field. I didn't write application side in dynamically-typed language yet.
Maybe date is not the best example. E-mail address is string, and can be passed with wrong format into interactor. In case of email I'd repeat client validation in interactor.
I leave protecting from SQL injection for gateways (for example hibernate/escaping comment character) and client (for example html encoding).