интеграция - это взаимодействие 2х интерфейсов. Она есть и между 2я микросервисами и между монолитом и сервисами. Дублировать ли инфу или нет зависит не от требований, а от выбранной архитектуры. Если люди решили что это мса, то дублирование инфы это часть архитектуры мса. Если не нравится факт дублирования или вам жалко пару гигов на винте - выбирайте другие подходы, например soa или живите в монолите, страдайте из-за других проблем
Нет. Каждому контексту свой микросервис. Это 1 иногда 2 агрегата, а не сущности.
связанные с ними данные хранятся там
Нет. сервис пользователей это лишь первоисточник данных. Все данные о пользователях, которые нужны другим микросервисами хранятся в БД тех микросервисов.
Это неверный подход. Верный подход: сервис отправляет в шину событие что его данные изменились, все сервисы, которому нужен кусок таких данных из очереди берут их и сохраняют у себя. Никто 2ой раз не опрашивает сервис.
Конечно же нет. Менять задачи в спринте - это табу. Иначе это не скрам, а что-то другое. scrumbut, например.
Самая идея неизменяемого спринта состоит в том, чтобы оградить команду от прибегающего чайка-менджера, которому срочно нужно.
miluk, скорее всего нет, потому что в суде юрист сайта скажет, что он не встречался с ивановым иваном ивановичем, который предоставил якобы доказательства, не имел возможности оценить их достоверность (где оригиналы? А вдруг поддельные) и т.д. А реагировать на жалобы @ванька99 с IP 1.1.1.123 сайт не обязан. Он же не знает кто такой ванька 99. Поэтому раз истец не выполнил все необходимые процедуры по предоставлению доказов и деанонимизации, то с сайта взятки гладки.
Если же это будет норм. оформленная жалоба (одна из 1000) то скорее всего сайт удалит коммент.
Более того, как только дело дойдёт до суда, то никакого ущерба взыскано не будет, так как ущерб - это определённый термин, который нужно считать и доказывать. А где он тут? У человеку сайт машину не поцарапал.
И ещё более того, если дело дойдёт до иска, то сайт скорее всего в досудебном заседании оценит док-ва, скажет то, что я написал выше: "мы вообще уже всё удалили, комментов нет, прошу иск отклонить". А раз дело не было принято к производству и отклонено, то никаких компенсаций.
miluk,
1. По законному требованию суда, которое не было отменено вышестоящим судум
2. Для этого должен состояться суда
3. Удаление комментариев - это не ответственность, это исполнение решения. Ответственности сайта здесь нет и быть не может.
Про монго написана полная чушь. RDBS базы данных сейчас нужны только в том случае, если у вас есть транзакции и вам важно гарантировать целостность при изменении. Например это платежи. Для хранения всех остальных данных, например описание сотрудников, ордеров, адресов, деталей сущностей нужно использовать только NoSQL базы данных, которые заточены под хранение данных, а не под гарантированность их целостности при параллельном редактировании. Почему? Потому что это быстрее в десятки раз. Потому что NoSQL не имеет всех тех тяжёлых наворотов на уровне архитектуры, которые нужны для ACID. А если ACID не нужен для всех данных а только для платежей, то нафига всё тащить в RDBS базу?
Использование RDBS для хранения всего и вся, да ещё и с навешиванием внешних ключей - считай конец нагруженному приложению, которому нужно поднять скажем 1.5-3 тысячи ордеров с данными о продуктах, листингах и т.д. (десяток другой таблиц, сотня колонок, ключи, джоины и от сюда локи на таблицы) Такой запрос будет идти от 30 секунд до таймаута. В то время как в nosql базе это будет 1-2 секунды максимум (это пример реального опыта с нагруженным продом)
когда вам не нужен ASID ( а он крайне редко нужен) - ваш выбор NoSQL решение.
Правильный выбор для 90% веб-приложений - это хранить все данные в NoSQL а когда речь заходит про транзакции и нужно гарантировать что-то, то часть этих данных (по айдишникам) должна храниться и обрабатываться в RDBS базе.
Кстати, из личного наблюдения: свято верят в непогрешимость и вечную жизнь реляционных баз, а также хранят там все данные и 80% бизнес логики программисты крайне низкой квалификации, которые остались своими решениями и сопутствующими проблемами в нулевых, если ни в 90ых. Надеюсь, что вы не такой и просто не любите монгу и JS :)
Можно ещё добавить, что если компания хочет обратиться в суд на того, кто жалобу оставил за клевету, то ваш сайт по требованию суда готов предоставить данные человека. Но сам сайт не несёт ответственность за жалобы. Ненадлежащий ответчик - самая железобетонная отмазка в любом суде.
netkovk: всё понятно. У вас наверное 8.1 или 10ка. На ней уже не стоит .net 3.5. Его нужно отдельно поставить. После этого правой кнопкой на проекте->properties-> build и там можно выставить версию .net для каждого проекта. А вообще гуглиться на раз "set framework version in Visual studio"
Пума Тайланд: ну фрилансер может работать и на 1 компанию постоянно. Хотя вы правы, он не написал что работает на одну, хотя написал, что доход постоянный (я это воспринял как работу на 1 компанию удалённо)
никакого предпринимательства в постоянной работе на 1 компанию по гражданско-правовому договору нет. Не выдумывайте свои трактовки. Предпринимательства это прибыль, которую он тратит на развитие и РИСКИ. Работник от рисков избавлен. Это простой договор по ГК.
Не обязан. Работодатель - иностранная компания, которая не подчиняется законам РФ. Никакие выплат никто делать не будет. Все соц. выплаты делаются с ФОТ.
Работник в этом случае становится сам своим налоговым агентом и платить 13% НДФЛ. Всё. При этом ему не идёт начисление пенсии. Надеюсь вы не юрист\бухгалтер, а то беда в стране.
sim3x: Кто тебе сказал что уволили? Никто не уволняет, просто наращивают долг по ЗП или делают невыносимыми условия работы. Знаю много примеров от Softserve до Swtitla Systems. + примеры с доу
- использование ORM: когда можно и нужно), когда хочется, но нельзя. - для бизнеса можно всегда, кроме случая когда у вас ботлнетрм является скорость обработки запроса ORMомо, что на практике мало достижимо и есть много чего другого оптимизировать чем трансляцию Expression в SQL. Обычно отказ от ORM это из-за неграмотности команды, где в качестве архитекторов системы сидят бывшие DBA и любители всё засунуть в хранимки, либо особенности архитектуры(например делая оболочку для MSSQL Studio нет смысла использовать ORM потому что надо напрямую писать в БД)
когда можно "толстую" ORM (Entity Framework, NHibernate), а когда - тонкую (LINQ to SQL); - вопрос столь несущественен, что надо брать ту, которую команда уже знает. Как правило это EF или Nh ну и к тому же рано или поздно захочется большего, а LtS не способен на большее. В итоге знать не надо, надо брать. И выбор делает программист, а не аналитики.
использование кода на стороне БД - триггеры, хранимые процедуры;
- принципы построения слоев доступа к данным в сочетании с бизнес логикой (паттерны и антипаттерны в этих ситуациях, например Anemic Data Model);
Вот это надо знать. Особенно про анти-паттерн Active Record.
kopch: тогда может прокатить. Хотя ваш круг клиентов - приложения которые разрабатываются 3-8 месяцев и лень тратить 1-2 месяца разбираться и использовать какими-нибудь яндекс-деньги. У нас была кстати подобная потребность для SmartTV приложения. Когда удобная оплата услуг внутри ТВ приложения (по сути SPA на Javascript) за каналы\контент. Т.е. это интересно ещё и владельцем таких сервисов для получения оплаты. Рекомендую привязать ещё смс банкинг. Люди, оказывается тупые и ленивые. Хотят просто смски отправлять, не палить карту свою.