Simple vehicle DDD model - to ValueObject techincal state or not

Question

I'm working on some PHP app where I'm using a Vehicle model.

This model should contain some data and probably logic regarding the vehicle controls, emission controls and some regular services. Here is code:

class Vehicle extends Entity {
    protected $name;
    protected $registrationNumber;
    protected $registrationCountry;
    protected $seatsCapacity;
    protected $obtainDate;
    protected $color;
    protected $comment;
    protected $naviSerialNumber;
    protected $fuelCardNumber;
    protected $techicalStatus;
    protected $transferStatus;
    protected $ownership;
}

where $technicalStatus should be a instance of such class:

class VehicleTechnicalStatus extends ValueObject {
    protected $tachoValue;
    protected $vehControlDate;
    protected $vehControlValidDue;
    protected $emissControlDate;
    protected $emissControlValidDue;
    protected $lastRegServiceTachoValue;
    protected $lastRegServiceDate;
    protected $serviceInterval;
}

Of course it will contain some logic regarding the vehicle control dates, services etc.

Is it correct to make such class a ValueObject? It hasn't any identity but in Vehicle it will be frequently changed (replaced, as its a ValueObject and should be immutable).

Is it correct design? Or should I place all these properties and business logic methods directly to Vehicle class?

Think about the behavior rather than data and it will become clear. In which circumstances will the technical status or any of it's members change? What kind of behavior would be performed that would cause the technical status to be replaced? Will all values always change together? No one can answer this question without behavioral knowledge of your domain, unless it's a well-known domain (e.g. financial). — plalx, May 13 '15 at 15:33
Thank you for advice, @plalx. The most valuable and often updated properties of the model are `$transferStatus` (its also a ValueObject class but it has only few simultaneously updated properties) and `$technicalStatus`. For more clear understand - the application domain is a scheduling and state tracking of company resources ( which are `Employee`, `Vehicle` and `Tool` ). The purpose of `Vehicle` is to have up-to-date data about where is the vehicle (project, responsible person) and its technical state so the responsible persons could schedule vehicle controls and service. — Konstantin Šuvakin, May 13 '15 at 17:54
@Try listening to your Ubiquitous Language here. "the **responsible persons** could **schedule** vehicle **controls** and **service**". These are the kind of behavior you want to explicitly model in your system. You know that you may have controls and services and the fact that these occurred might impact the technical status of the vehicle. Perhaps this may be done through a behavior such as `vehicule.control(controlDetails, responsibleEmployee)`. You may also have `vehicule.scheduleControl(..., responsibleEmployee)`. The behavior will tell you what data should be bundled together. — plalx, May 13 '15 at 18:13
Perhaps the `technicalStatus` of a vehicule is simply derived from past `VehiculeControlEvent`s and `VehiculeServiceEvent`s. I can't tell you what is right or wrong without more knowledge of your domain, but I hope that this will help to put you on the right track. — plalx, May 13 '15 at 18:17
@plalx, i'm not sure if i have use correct term. The vehicle control (or inspection ) is law regulation [link](http://en.wikipedia.org/wiki/Vehicle_inspection). And i'm sorry, my comment isn't complete - the second key purpose of `$technicalStatus` is do prevent transfer to project of `Vehicle` that have expiring vehicle inspection or emission control etc. It seems that only business rule in this ValueObject could be implemented in one method - isTranferable(). Looks like there is no reason for such Value Object, these data and method could stay in `Vehicle` class. Thank you for advice. — Konstantin Šuvakin, May 13 '15 at 18:23
Well like I said, perhaps you should keep a record of all control actions as well as service actions that were performed on the vehicle rather than simply keeping the latest values as an aggregated state. Also keep in mind that when you see variables all with the same prefix, you are given the chance to make that concept explicit by modeling a conceptual whole. Think about it, `$lastRegServiceTachoValue` and `$lastRegServiceDate` will always change together. In an append-only model, they would perhaps be modeling as a `ServiceEvent`. — plalx, May 13 '15 at 19:01

score 0 · Answer 1 · answered Jan 08 '18 at 02:37

Is it correct to make such class a ValueObject? It hasn't any identity but in Vehicle it will be frequently changed (replaced, as its a ValueObject and should be immutable).

Yes. Fundamentally, value objects are domain specific types that are composed of other domain specific types and domain agnostic primitives.

Which is to say: if PHP had a native VehicleTechnicalStatus type, you would just use that, but it doesn't so you roll your own.

Or should I place all these properties and business logic methods directly to Vehicle class?

If VehicleTechnicalStatus is used outside of the Vehicle entity -- in particular, if you are expecting to pass VehicleTechnicalStatus as an argument to some function, then you probably want to treat it as an encapsulated type, distinct from the Vehicle property bag. You lose some on complexity (two different modules instead of one large on), but you gain on context -- when you are working on the technical status, you can keep your focus entirely there, without distraction from the other unrelated fields in Vehicle.

Simple vehicle DDD model - to ValueObject techincal state or not

1 Answers1