Алексей
линолиум
Anonymous
Ща дебиан подтянет
Anonymous
И вообще
Anonymous
Anonymous
Я фотку из за последней строки скинул
Алексей
это китаец чтоли?
Anonymous
7 часов танцевал с рекавери грабом и он мне выдает elf magic и отключается через 15 минут
Anonymous
Утром встал, за пол часа востановился._.
Алексей
а.. все перепутал
Евгений
Всем привет! Подскажите, есть ли какой-то ONLINE верстальщик? Мне нужно сверстать страницу статьи в opencart
Алексей
для тестеровщиков безопасности ..
Anonymous
Алексей
Anonymous
Есть нейросеть
Anonymous
Простенькую верстку тянет
Anonymous
Жрет много правда
Sander
Всем привет
Sander
есть кто работал с symfony и знает что такое bounded context?
Алексей
далек от верстки, когда делаю, вроде все текстом пишу обычным
Anonymous
FloydHub
Anonymous
Погугли
🐴
🐴
https://martinfowler.com/bliki/BoundedContext.html
Алексей
вот блин.. болела голова. нафигачил себе мороженка с коньячком и кофейком... голова прошла.. но и работать что то расхотелось :))
Anonymous
Мистер лршадь, вы чего нибудь вообще не знаете?
Sander
некоторые вещи в symfony не состыкутся с bounded context логикой
🐴
🐴
Anonymous
вин 10 вообще не удовлетворяет
Anonymous
Ну я бы поспорил
🐴
Anonymous
За ту же сумму что стоит прошка, я возьму себе рабочий омен и игровой алиен
Anonymous
Так что хз
Anonymous
:(
🐴
🐴
А
🐴
Да вроде с ней не должно быть проблем
Anonymous
вот за это побаиваюсь. ну и телега не нравится мне как на линупсе ставится.
Anonymous
Anonymous
Sander
@f3ath в symfony если работаешь с базой, то таблицу и его поля с типами - ты описываешь в Entity.
Потом делаешь миграцию, все очень удобно.
---
но если я использую bounded contects в проекте,
то у меня может быть два класса Product (entity) с разными параметрами, но они будут в разных bc,
это чтоб не плодить один большой класс, где будут храниться все возможные параетры в проекте (нам не надо хранить все в одном, потому что нам нужно только то что используется в текущем bc).
---
а так как мы описываем таблицу в базе через Entity, то у нас не получится создать два класса Product в разных bc,
потому что symfony требуется один класс для того чтоб сделать миграцию для определенной таблицы.
- Собственно думаю как можно сделать иначе, так как правильно все токи разделять.
Anonymous
Мак может и норм бы был в моих глазах, если бы они так активно не зарезали терминал
🐴
@f3ath в symfony если работаешь с базой, то таблицу и его поля с типами - ты описываешь в Entity.
Потом делаешь миграцию, все очень удобно.
---
но если я использую bounded contects в проекте,
то у меня может быть два класса Product (entity) с разными параметрами, но они будут в разных bc,
это чтоб не плодить один большой класс, где будут храниться все возможные параетры в проекте (нам не надо хранить все в одном, потому что нам нужно только то что используется в текущем bc).
---
а так как мы описываем таблицу в базе через Entity, то у нас не получится создать два класса Product в разных bc,
потому что symfony требуется один класс для того чтоб сделать миграцию для определенной таблицы.
- Собственно думаю как можно сделать иначе, так как правильно все токи разделять.
$product = new SalesProduct($productEntity); // один bc
$product = new SupportProduct($productEntity); // другой bc
Sander
вопросы походу не понял
Anonymous
Я сам не маковод, но дизайнер в офисе у меня все стены заплювал от ХайСиеры
Anonymous
По этому могу только рассуждать, основываясь на услышанном от владельца
Алексей
плохому танцору..... и линукс мешает
Anonymous
:))
Sander
что-то тут не очень понятно, у тебя тут entity $productEntity,
который ты кладуешь в инстанс класса SalesProduct, который является чем? тоже entity?
$product = new SalesProduct($productEntity); // один bc
$product = new SupportProduct($productEntity); // другой bc
Anonymous
Я уточнил что говорил про свое мнение:)
🐴
🐴
интерфейс SalesProduct содержит только то, что актуально для Sales
🐴
таким образом ты сможешь в будущем, когда у тебя контексты станут совсем разными, выделить отдельный SalesProduct который будет как-то иначе храниться, станет отдельной entity например
🐴
раз у тебя используется так же самая entity в разных контекстах, возможно, они не так сильно отличаются
Sander
я знаю что такое адаптер, но пока всей картины все равно не вижу
🐴
ну тебе надо внутри контекста видеть только то, что актуально для него. адаптер - самое простое решение
Sander
ну они всегда будут похожи, так как в них всегда будет id, firstname, lstname - самые главные параметры
Sander
все остальное будет разным
🐴
надо будет - совсем разделишь их, будешь DTO передавать через границу
Sander
как я могу их взять и разделить, ведь на этом завязана то как база выглядеть будет
Sander
там же прямо в entity создаешь таблицу и колонки:
/**
* @ORM\Entity(repositoryClass="App\Repository\ProductRepository")
*/
class Product
{
/**
* @ORM\Id
* @ORM\GeneratedValue
* @ORM\Column(type="integer")
*/
private $id;
🐴
Sander
ну так симфони устроен
Sander
я от куда знаю, почему у них так это создается
🐴
значит у тебя слишком сильный coupling с фреймворком.
Sander
поэтому я и пришел сюда с этим вопросом
🐴
в центре всего должна быть доменная модель. она не должна зависеть ни от чего кроме домена.
🐴
все остальное зависит от модели
🐴
модель, он нее зависят интеракторы, от них зависит приложение, от него зависят контроллеры
Evgeniy
о святой ddd
🐴
фреймворку место за пределами приложения