DDD: Using Value Objects inside controllers?

Question

When you receive arguments in string format from the UI inside you controller, do you pass strings to application service (or to command) directly ?

Or, do you create value objects from the strings inside the controller ?

new Command(new SomeId("id"), Weight.create("80 kg"), new Date())

or

new Command("id", "80 kg", new Date())
new Command("id", "80", "kg", new Date())

Maybe it is not important, but it bothers me.

The question is, should we couple value objects from the domain to (inside) the controller ?

Imagine you don't have the web between you application layer and the presentation layer (like android activity or swing), would you push the use of value objects in the UI ?

Another thing, do you serialize/unserialize value objects into/from string like this ?

Weight weight = Weight.create("80 kg"); 
weight.getValue().equals(80.0);
weight.getUnit().equals(Unit.KILOGRAMS);
weight.toString().equals("80 kg");

In the case of passing strings into commands, I would rather pass "80 kg" instead of "80" and "kg".

Sorry if the question is not relevant or funny.

Thank you.

UPDATE

I came across that post while I was searching information about a totally different topic : Value Objects in CQRS - where to use

They seem to prefer primitives or DTOs, and keep VOs inside the domain.

I've also taken a look at the book of V. Vernon (Implementing DDD), and it talks about (exactly -_-) that in chapter 14 (p. 522)

I've noticed he's using commands without any DTOs.

someCommand.setId("id");
someCommand.setWeightValue("80");
someCommand.setWeightUnit("kg");
someCommand.setOtherWeight("80 kg");
someCommand.setDate("17/03/2015 17:28:35");
someCommand.setUserName("...");
someCommand.setUserAttribute("...");
someCommand.setUserOtherAttributePartA("...");
someCommand.setUserOtherAttributePartB("...");

It is the command object that would be mapped by the controller. Value objects initialization would appeare in the command handler method, and they would throw something in case of bad value (self validation in initialization).

I think I'm starting to be less bothered, but some other opinions would be welcomed.

You mean "what about using DTOs" ? ^^; Indeed, I have not talked about that in my question — resehuvija
I think you mean "I've noticed he's using commands without any VOs." (you say "DTOs" instead). — prograhammer

eouw0o83hf eouw0o83hf · Accepted Answer · 2015-03-17T06:38:04

As an introduction, this is highly opinionated and I'm sure everyone has different ideas on how it should work. But my endeavor here is to outline a strategy with some good reasons behind it so you can make your own evaluation.

Pass Strings or Parse?

My personal preference here is to parse everything in the Controller and send down the results to the Service. There are two main phases to this approach, each of which can spit back error conditions:

1. Attempt to Parse

When a bunch of strings come in from the UI, I think it makes sense to attempt to interpret them immediately. For easy targets like ints and bools, these conversions are trivial and model binders for many web frameworks handle them automatically.

For more complex objects like custom classes, it still makes sense to handle it in this location so that all parsing occurs in the same location. If you're in a framework which provides model binding, much of this parsing is probably done automatically; if not - or you're assembling a more complex object to be sent to a service - you can do it manually in the Controller.

When parsing fails ("hello" is entered in an int field or 7 is entered for a bool) it's pretty easy to send feedback to the user before you even have to call the service.

2. Validate and Commit

Even though parsing has succeeded, there's still the necessity to validate that the entry is legitimate and then commit it. I prefer to handle validation in the service level immediately prior to committing. This leaves the Controller responsible for parsing and makes it very clear in the code that validation is occurring for every piece of data that gets committed.

In doing this, we can eliminate an ancillary responsibility from the Service layer. There's no need to make it parse objects - its single purpose is to commit information.

When validation fails (someone enters an address on the moon, or enters a date of birth 300 years in the past), the failure should be reported back up to the caller (Controller, in this case). While the user probably makes no distinction between failure to parse and failure to validate, it's an important difference for the software.

Push Value Objects to UI?

I would accept parsed objects as far up the stack as possible, every time. If you can have someone else's framework handle that bit of transformation, why not do it? Additionally, the closer to the UI that the objects can live, the easier it is to give good, quick feedback to the user about what they're doing.

A Note on Coupling

Overall, pushing objects up the stack does result in greater coupling. However, writing software for a particular domain does involve being tightly coupled to that domain, whatever it is. If a few more components are tightly coupled to some concepts that are ubiquitous throughout the domain - or at least to the API touchpoints of the service being called - I don't see any real reduction in architectural integrity or flexibility occurring.

Parse One Big String or Components?

In general, it tends to be easiest to just pass the entire string into the Parse() method to get sorted through. Take your example of "80 kg":

"80 kg" and "120 lbs" may both be valid weight inputs
If you're passing in strings to a Parse() method, it's probably doing some fairly heavy lifting anyway. Expecting it to split a string based on a space is not overbearing.
It's far easier to call Weight.create(inputString) than it is to split inputString by " ", then call Weight.create(split[0], split[1]).
It's easier to maintain a single-string-input Parse() function as well. If some new requirement comes in that the Weight class has to support pounds and ounces, a new valid input may be "120 lbs 6 oz". If you're splitting up the input, you now need four arguments. Whereas if it's entirely encapsulated within the Parse() logic, there's no burden to outside consumers. This makes the code more extensible and flexible.