мой любимый вопрос - где в аббривиатуре "ООП" слово класс?

Нигде)

Экземпляр класса

то есть "объект" это некая рантайм структура данных с указателями на процедуры?

то есть Си в каком-то смысле объектно ориентированный язык?

структура данных с указателями, а за окном хрущевская оттепель

то есть "объект" это некая рантайм структура данных с указателями на процедуры?

Ну технически да

то есть Си в каком-то смысле объектно ориентированный язык?

Получается что так

структура данных с указателями, а за окном хрущевская оттепель

ну вот я сча с DCI разбираюсь.... там "объект" представлен как некая структура данных, а поведение хранится в ролях.... и контекст задает твоим данным некие роли

Наставь меня на путь истинный)

они не существуют поодиночке - их согнали в классы

Наставь меня на путь истинный)

из того что я уже на эту тему прочитал все упирается в то.... что ООП нет. Нету. Не придумали. А все описывают как эталонное ООП на джаве не сделать. На C++ больше шансов сделать эталонное ООП чем на джаве

попробуй сформулировать то, как ты видишь объект

Для определения объекта мне требуется определение переменной)

Для определения объекта мне требуется определение переменной)

переменной именно или стэйта?

из того что я уже на эту тему прочитал все упирается в то.... что ООП нет. Нету. Не придумали. А все описывают как эталонное ООП на джаве не сделать. На C++ больше шансов сделать эталонное ООП чем на джаве

Ну ладно, оставим эталонное ООП на джаве Егору Бугаенко) Как архитектурно реализовать взаимодействие между разными контекстами?

Ну ладно, оставим эталонное ООП на джаве Егору Бугаенко) Как архитектурно реализовать взаимодействие между разными контекстами?

самый популярный вариант - ивенты

Господа, как называется система с четко выраженной пайповой структурой чтения данных и записи

переменной именно или стэйта?

Переменной

Переменной

мммм..... имутабельная переменная все еще переменная?

самый популярный вариант - ивенты

Я в вебе, и у меня CQRS, и я делаю квери. Ивенты - чёт такой себе вариант. Есть ещё какие-то способы?

приложение с архитектурой Unix

мммм..... имутабельная переменная все еще переменная?

очевидно, зависит от того, что такое переменная ))

Я в вебе, и у меня CQRS, и я делаю квери. Ивенты - чёт такой себе вариант. Есть ещё какие-то способы?

у тебя проблема с тем что одному контексту для чего-то нужны данные из другого контекста?

у тебя проблема с тем что одному контексту для чего-то нужны данные из другого контекста?

Именно

Именно

тебе для UI или для логики?

для UI - пусть что-то сверху соберет их двух контекстов данных себе

тебе для UI или для логики?

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

для логики - надо смотреть и думать как можно перераспределить границы... либо через eventual consistency копировать данные по контекстам но это боль и ад

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

странные у тебя ограниченные контексты раз они не ограниченные....

для UI - пусть что-то сверху соберет их двух контекстов данных себе

Думали над этим как один из вариантов. Хотелось бы всё таки сделать одним вызовом, если это возможно.

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

почему это два контекста?

один контекст и 2 базы?

почему это два контекста?

Потому что они оперируют совершенно разными понятиями

И одно и то же в зависимости от контекста - имеет разный смысл

Вполне себе кандидаты на раздельные контексты

Переменной

переменная это идентификатор, позволяющий нам передавать/ссылаться на значения.

один контекст и 2 базы?

2 контекста. У одного есть база, второй - это сервис, взаимодействующий с внешним апи.

Ну и соответственно моя категория товаров - эта не та же категория товаров, что в этом внешнем сервисе

Ну вот есть у меня контекст, где я храню свои товары и есть отдельный контекст, гд производится поиск аналогов - я оттуда получаю артикулы и производителей, по которым я в свой базке должен найти те товары, которые у меня есть. Как такое грамотно сделать? Сервис какой-то написать?

я бы делал в 2 запроса последовательных из третьей штуки. У тебя так и так выходит в 2 запроса.

И мой товар - не тот же, что и во внешнем сервисе

И мой товар - не тот же, что и во внешнем сервисе

ты из внешнего сервиса достаешь идентификаторы и по ним потом у себя ищешь

я бы делал в 2 запроса последовательных из третьей штуки. У тебя так и так выходит в 2 запроса.

Вот куда эту третью штуку запихать?)

ты из внешнего сервиса достаешь идентификаторы и по ним потом у себя ищешь

Именно

Ну производителя и артикул

У нас просто все сервисы относятся к какому-то контексту. А нужно как-то эти 2 контекста объединить. Результатом выборки будут сущности из моего контекста.

....мне кажется тут какое-то выделение контекстов ради выделения контекстов

Вот куда эту третью штуку запихать?)

другой вопрос - куда запихнуть процесс затрагивающий пару контекстов? ну там сагу ту же

....мне кажется тут какое-то выделение контекстов ради выделения контекстов

Ну эта штука на первых порах будет жить в том же процессе, что и мой локальный контекст, а потом в отдельный процесс и микросервис мимикрирует

и при этом все еще иметь возможность быстро осмотреть весь процесс

другой вопрос - куда запихнуть процесс затрагивающий пару контекстов? ну там сагу ту же

Тут чтение. Саги же про команды вроде больше.

а какая разница?)

ну то есть проблема одна и та же - есть штука которая как бы... сверху

над твоими контекстами

над твоими контекстами

Ну чисто технически я возвращаю данные из своего контекста

в случае UI это какой-то гейтвей

в случае саг это может быть какой-то менеджер процессов

Мб какой-то клиент сделать и его дергать из своего контекста?

Ну чисто технически я возвращаю данные из своего контекста

то есть твой контекст будет знать о другом контексте

Он будет знать о клиенте только

https://habrahabr.ru/post/325092/

Мб какой-то клиент сделать и его дергать из своего контекста?

не все что у тебя в приложении является "частью контекста". Есть еще банальная инфраструктура. Есть что-то на уровне приложения.

И о понятиях, которые в нем самом же есть

https://habrahabr.ru/post/325092/

Почитай Егора Багуенко

Он будет знать о клиенте только

о клиенте?

https://habrahabr.ru/post/325092/

TL DR разбросанные по проекту new лучше чем SimpleInjector?

о клиенте?

О клиенте, который скроет от нас знания из другого контекста.

Почитай Егора Багуенко

на русском

TL DR разбросанные по проекту new лучше чем SimpleInjector?

Эксобар

О клиенте, который скроет от нас знания из другого контекста.

чеее?

о, давай.... дай определение термину "ограниченный контекст"

чеее?

Блин адаптер

Для определения объекта мне требуется определение переменной)

ну так что на счет моего определения?

Ну типа там какой-то сервис, оперирующий своими сущностями внутри, но мне наружу от него надо совсем немножко данных, вот только их я и заберу.

переменная это идентификатор, позволяющий нам передавать/ссылаться на значения.

Следовательно, объект — это область в памяти, хранящая значение, на которую ссылается переменная. Подвох в том, что из другого определения переменной следует другое определение объекта, можно даже и другие определения подсовывать, типа функции

И знать не буду о том как оно под капотом устроено и работает. Сделать простой контракт.

Следовательно, объект — это область в памяти, хранящая значение, на которую ссылается переменная. Подвох в том, что из другого определения переменной следует другое определение объекта, можно даже и другие определения подсовывать, типа функции

окей.... то есть по факту объект это некий стэйт.... а поведение че куда?

то есть на уровне рантайма у тебя так или иначе стэйт объекта отдельно а поведение отдельно

и ты просто задаешь поведению контекст

@fes0r попахивает или нет?

@fes0r попахивает или нет?

хз.... лишь бы небыло войны

хз.... лишь бы небыло войны

Ты бы плевался от такого?

Следовательно, объект — это область в памяти, хранящая значение, на которую ссылается переменная. Подвох в том, что из другого определения переменной следует другое определение объекта, можно даже и другие определения подсовывать, типа функции

а теперь давай рассуждать.... ключевой концепцией ООП было message passing....

Или можно жить?

Ты бы плевался от такого?

откуда ж я знаю)

откуда ж я знаю)

Поставь мысленный эксперимент))

Поставь мысленный эксперимент))

не сейчас....

хз я.... у меня был бы api gateway который бы сначала дернул сервис который бы вернул артикли а потом яб ы попросил другой сервис собрать мне продукты по этим артиклям

если бы это стало неудобным - думал бы дальше

хз я.... у меня был бы api gateway который бы сначала дернул сервис который бы вернул артикли а потом яб ы попросил другой сервис собрать мне продукты по этим артиклям

То есть пусть фронт это дергает?

То есть пусть фронт это дергает?

api gateway, нечто между твоими контекстами и фронтом

а теперь давай рассуждать.... ключевой концепцией ООП было message passing....

Смотри в чём финт: мы построили объекты от переменных. но это не единственный валидный вариант, тут как с неевклидовой геометрией) Можно определить inbox и message, сформулировав акторы, и сделать object как поток сообщений об изменении

ну хз, короч

Смотри в чём финт: мы построили объекты от переменных. но это не единственный валидный вариант, тут как с неевклидовой геометрией) Можно определить inbox и message, сформулировав акторы, и сделать object как поток сообщений об изменении

почему поток сообщений?

объекты = экторы а соль в сообщениях

плевать на объекты и что это такое, соль в том что есть что-то что взаимодействует. Если у тебя один объект - у тебя не ООП

Ну у нас время как ни крути линейно, а object в единственном числе

Ну у нас время как ни крути линейно, а object в единственном числе

....мне кажется это какая-то наркомания

api gateway, нечто между твоими контекстами и фронтом

Ну да, есть у меня такой. Просто фронт дергает апишку, та отправляет запросы в один контекст и возвращает результаты, а потом на их основе делает ещё один запрос, который уже внутри моего контекста искать будет

Верно?

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

The AlanKay definition of OO is largely that given by CarlHewitt for the ActorsModel which is a model of computation, not a programming paradigm. AlanKay has acknowledged explicitly this derivation. Versions of Smalltalk before Smalltalk-80 were still largely based on the (asynchronous, unidirectional) ActorsModel of computation, but with Smalltalk-80, the developers of SmalltalkLanguage switched entirely to the (synchronous, bidirectional) procedural model, while misleadingly retaining the ActorsModel terminology (such as "messages" for what essentially are procedure calls rather than one-way notifications). This has caused endless terminological difficulties especially when considering that the the other major sources of OO thinking--capability architectures and the SIMULA 67 research--were not in the least inspired by ActorsModel thinking.