здесь можно было развести долгую дискуссию, а какое дело программисту до проблем заказчика (к тому же, кто с ними долго работал знают - что там все примитивно - вложить миллион, через год получить десять), но не буду...
Одни программисты растут по должности, и стремятся общаться напрямую с заказчиками, другие наоборот, возвращаются в чистые программисты, чтобы быть подальше от конкретных заказчиков, с их абстрактными хотелками
"а какое дело программисту до проблем заказчика" - и рассуждения на тему ddd где все крутится вокруг анализа problem space заказчика и переноса этого всего на solution space. вот тут конфликт.
Все верно. Одна лишь разница - заказчик перетаскивает программиста на свою поляну, с абстрактными проблемами, или программист перетаскивает заказчика на свою поляну, требуя четких ТЗ и описаний бизнес-логики
обычно все сложнее - заказчик перетаскивает программиста на поляну кривых решений и предположений не подкрепленных фактами и тебе надо каким-то образом (самостоятельно, с помощью продукт менеджеров или там ux интервью) разобраться что на самом деле является проблемой, кого она затрагивает (что бы ты мог контексты правильно выделять) и т.д. и т.п.
ну что ж, теперь все становится окончательно понятно
Если для вас принципиально, в какой папочке находится код - то обсуждать нечего. Я могу разместить код в любой другой папке, обновить composer.json и все
@fes0r вопрос будет более прямой по теме. Как бы вы сделали реализацию боя? Ну вот допустим есть атака, деф, крит шанс, хп. 2 юнита (или не юнита?). Ну чтобы без геттеров, чтобы без сущностей отражающих реальный мир (т.е. в данном случае юнит)