КГ
Я не отстаиваю тот или иной вариант если чо
Size: a a a
2020 May 05
Р
Не оч понятно куда во-втором варианте общие вещи девать. Ещё одна Infrastructure в коре?
Нахренячивают в src полным списком
КГ
Пытаюсь понять куда двигаться
VT
У меня опять тупой вопрос про папочки. Вот эти App,Domain,Infra - их обычно только в корне проекта делают, или в каждом контексте свои?
мы и так и так пробовали.
если в корне - получаются слои. которые ложь, но всё еще удобнее стандартной структуры с Entity\Service\etc.
если сделать внутри каждого контекста - приходишь к мысли что эти папочки нахер не нужны и остаешься просто с контекстами. что удобнее чем слои, имо.
если в корне - получаются слои. которые ложь, но всё еще удобнее стандартной структуры с Entity\Service\etc.
если сделать внутри каждого контекста - приходишь к мысли что эти папочки нахер не нужны и остаешься просто с контекстами. что удобнее чем слои, имо.
AM
вам наверн в ооп чат пора
BT
а еще лучше не называть вещи Application/Domain/Infrastructure
МФ
Руслан
Чем структура
Application
User
Product
Domain
User
Product
Infrastructure
User
Product
Лучше, чем
User
Application
Domain
Infrastructure
Product
Application
Domain
Infrastructure
И так говно, и так насрано
Application
User
Product
Domain
User
Product
Infrastructure
User
Product
Лучше, чем
User
Application
Domain
Infrastructure
Product
Application
Domain
Infrastructure
И так говно, и так насрано
откуда в Application взялся User?
КГ
а еще лучше не называть вещи Application/Domain/Infrastructure
1) Почему 2) А как называть?
AM
а еще лучше не называть вещи Application/Domain/Infrastructure
они это уже читали (кажется)
Р
вам наверн в ооп чат пора
В ддд наркота
VT
откуда в Application взялся User?
ну дык слой приложения для контекста юзера, усё логично
BT
1) Почему 2) А как называть?
потому, что слои - это ложь)
AM
1) Почему 2) А как называть?
там по ссылке же описано
ЕР
мы и так и так пробовали.
если в корне - получаются слои. которые ложь, но всё еще удобнее стандартной структуры с Entity\Service\etc.
если сделать внутри каждого контекста - приходишь к мысли что эти папочки нахер не нужны и остаешься просто с контекстами. что удобнее чем слои, имо.
если в корне - получаются слои. которые ложь, но всё еще удобнее стандартной структуры с Entity\Service\etc.
если сделать внутри каждого контекста - приходишь к мысли что эти папочки нахер не нужны и остаешься просто с контекстами. что удобнее чем слои, имо.
+ тож думаю что внутри контекста делить оч неудобно вышло
МФ
ну дык слой приложения для контекста юзера, усё логично
не нет
КГ
потому, что слои - это ложь)
Да при чём тут слои опять)))
VT
не нет
это ирония была )
BT
Да при чём тут слои опять)))
потому, что app/domain/infrastructure - это имитация слоев
Р
откуда в Application взялся User?
Ок, команды-запросы-хендлеры, условно
Р
Но разделенные по user, product