Сопоставление доменов - преобразование моделей из внешнего программного обеспечения во внутреннюю структуру - PullRequest
0 голосов
/ 11 сентября 2018

Я сейчас работаю над php-фреймворком, чтобы абстрагироваться и сделать его интересным и простым в работе с внешним программным обеспечением ($ ES), к которому обращается моя компания. Мой подход - шестиугольная модель дизайна, которая до сих пор прекрасно работает. Моя единственная задача - сопоставить (и где отобразить) сущности из $ ES с нашей внутренней структурой.

Пример: $ externalSoftwareProduct (своего рода класс бога, который обрабатывает все) сопоставляется с $ internalFrameworkProduct (и многими другими классами для разделения обязанностей). Это происходит в хранилищах. В каждом методе хранилища я собираю эти сущности из $ ES и делаю

new $internalFrameworkProduct(some arguments here coming from 
$externalSoftwareProduct)

foreach моих собранных сущностей, которые затем возвращаются. В этих репозиториях есть только общие методы, такие как getById, getAll, вы называете его.

Теперь мы используем эту инфраструктуру в проекте заказчика и расширяем эти базовые классы с помощью расширения, специфичного для домена, например CustomerNameProductRepository. Там вы найдете специфичные для домена методы, такие как getProductsCustomerAlwaysNeeds и так далее. В конце этих методов мы сопоставляем $ internalFrameworkProduct с $ customerSpecificProduct, который содержит данные для более легкого доступа, который необходим. Метод в этом конкретном репозитории выглядит следующим образом.

public function getProductsCustomerAlwaysNeeds()
{
   $dataStuff = parent::getSomeStuff();
   /** @var internalFrameworkProduct[] $products **/
   $products = magic();

   foreach($products as $product)
   {
     $customerProducts[] = $this->getCustomerSpecificProduct($product->getId());
   }

   return $customerProducts;
}

public function getCustomerSpecificProductById(int $productId)
{
   $externalSoftwareProduct = new externalSoftwareProduct($productId)
   $customerSpecificProduct = new CustomerSpecificProduct(some arguments here coming from $externalSoftwareProduct)

   return $customerSpecificProduct;
}

Теперь все работает нормально. Единственная проблема в модульных тестах. Мы используем phpunit + Mockery. Чтобы смоделировать эти новые созданные экземпляры, мы должны использовать mock (перегрузка: externalSoftwareProduct) и mock (перегрузка: CustomerSpecificProduct), что всегда является проблемой (особенно если вы пытаетесь протестировать это с несколькими экземплярами, что время от времени требуется) . * * 1011

Как бы вы подошли к этому? Должен быть лучший способ подключить эти 3 части (externalSoftwareProduct, internalFrameworkProduct и CustomerSpecificProduct (который расширяет internalFrameworkProduct)).

Я думал об использовании фабрики для CustomerSpecificProduct, чтобы просто издеваться над фабрикой и позволить ей выплевывать мои продукты. Но я чувствую, что я перерабатываю такую ​​простую задачу.

1 Ответ

0 голосов
/ 11 сентября 2018

«.... отображение (и где отобразить) сущностей из $ ES в нашу внутреннюю структуру ...»

В адаптере, который вы используете для доступа к внешнему программному обеспечению.

...