Я работаю над некоторым приложением PHP, где я использую Vehicle
модель.
Эта модель должна содержать некоторые данные и, возможно, логику, касающуюся управления транспортным средством, контроля выбросов и некоторых регулярных служб. Вот код:
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;
}
где $technicalStatus
должен быть экземпляром такого класса:
class VehicleTechnicalStatus extends ValueObject {
protected $tachoValue;
protected $vehControlDate;
protected $vehControlValidDue;
protected $emissControlDate;
protected $emissControlValidDue;
protected $lastRegServiceTachoValue;
protected $lastRegServiceDate;
protected $serviceInterval;
}
Конечно, он будет содержать некоторую логику в отношении дат контроля транспортных средств, услуг и т. Д.
Правильно ли сделать такой класс ValueObject
? Это не имеет никакой идентичности, но в Vehicle
это будет часто изменено (заменено, так как его ValueObject
и должен быть неизменным).
Это правильный дизайн? Или я должен поместить все эти свойства и методы бизнес-логики непосредственно в Vehicle
учебный класс?
Правильно ли сделать такой класс ValueObject? У него нет идентификатора, но в Vehicle оно будет часто изменяться (заменяться, так как его ValueObject и должно быть неизменным).
Да. По сути, объекты значения являются специфичными для домена типы которые состоят из других типов, специфичных для домена, и не зависящих от домена примитивов.
Что сказать: если бы у PHP был нативный VehicleTechnicalStatus
типа, вы бы просто использовали это, но это не так, вы катите свой собственный.
Или я должен поместить все эти свойства и методы бизнес-логики непосредственно в класс Vehicle?
Если VehicleTechnicalStatus
используется за пределами Vehicle
сущность — в частности, если вы ожидаете передать VehicleTechnicalStatus как аргумент к какой-то функции, то вы, вероятно, захотите рассматривать ее как инкапсулированный тип, отличный от пакета свойств Vehicle. Вы теряете некоторые по сложности (два разных модуля вместо одного большого), но вы выигрываете по контексту — когда вы работаете над техническим статусом, вы можете полностью сосредоточиться на нем, не отвлекаясь от других не связанных полей в Vehicle.
Других решений пока нет …