Именно так. Более 10 лет разрабатывал под BPM, а ситуация все та же. Сначала вам задвигают Дорогое Красивое Решение, которое предендует на роль швейцарского ножа на все случаи жизни. Уже в процессе внезапно оказывается, что лезвия нихрена не режут, тупые, маленькие, пользоваться им не удобно или по большей части существуют как декорация. В итоге весь цикл разработки — это горожение велосипедов в борьбе с ограничениями платформы, и постепенная миграция критического функционала из BPM на самописку вплоть до полного отказа от этой самой BPM.
вот именно почему сказано:
Вместо того, чтобы помещать BPM движок в центр нашего бизнес-процесса, мы используем его как вспомогательный фреймворк. Руководящая роль в этом случае отводится .NET-приложению
Как по мне успех пришел изза бума микросервисов. Нода навела шумиху, а потом появился Го. И мечта пхп разработчиков о типизованом и маленьком сервисе стала явью. Я сам так делал и люди вокруг (Киев) по конференциях тоже ( даже вот такое придумали: https://github.com/spiral/roadrunner)
Мне кажеться, что вся шумиха шла из лагерей php, node, возможно Python.
Го отлично подходит к таким проектам как микросервис
Лично мне, как пользователю Го только в качестве маленького микросервиса с малий зоною ответственности дженериков не надо.
Для себя в компании приняли такое правило — при планировании всегда рассчитывать только на 5 продуктивных часов в день из 8 ми.
У всех есть митинги, всем нужно отойти выпить кофе или еще что. С тех пор, даже burndown почти совпадает (оценка в сторипоинтах) и за 4 года никто не жаловался.
Как по мне упущено самое важное: стоимость инфраструктуры (окружения) и ее поддержка для тестирования и собственно зарплата тестировщиков. Допустим можно убрать ЗП из расчета, но игнорировать затраты на инфраструктуру и ее поддержку — нельзя. Есть опит когда эти затраты неоправданны
Есть техники позволяющие не хранить сессию на стороне сервера. Недавно читал, как сесии хранят в Json Web Token. Думаю далеко не один способ существует для организации чистого stateless
И тут меня озарило: может быть, решение состоит в том, чтобы выявлять не фейковые новости, а достоверные. Достоверные новости куда проще свести в единую категорию.
Хмм. Похоже на «Все счастливые семьи счастливы одинаково, каждая несчастливая семья несчастлива по-своему». Как раз где-то на Хабре недавно даже статья проскакивала.
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним
это конечно хорошо, но не всегда компания продуктовая. В out-source/out-stuff Project Manager может никак не влиять на видение продукта. И в таких проектах запросто может не быть отдельного Product Owner`а. Да и в продуктовой компании порою нету ни PO ни BA (как правило в мелких по размеру компаниях). В таких случаях, как раз возможно принятие роли PO каким-то PM`ом так как скорее всего именно он общаеться с клиентом/маркетом/бизнесом. В етом нет ничего плохого.
Как по мне, то в коментариях к оригинальной статье верно подметили:
1. В примере БМПО связан уровень доступа к данным и уровень бизнес-логики
2. БМПО спроектировано плохо:
«Когда клиент отправляется в магазин, он держит товар/товары и отправляет их в кассу, чтобы купить их.Это не ответственность клиентов, чтобы сказать, может ли он купить свои товары, это ответственность сопутствующего лица в кассе.»
Советую вам попробовать github.com/KnpLabs/KnpGaufretteBundle для абстракции над файловой системой. Удобнее будет потом с переездом куда нибудь (если планируеться или придеться).
вот именно почему сказано:
Как по мне успех пришел изза бума микросервисов. Нода навела шумиху, а потом появился Го. И мечта пхп разработчиков о типизованом и маленьком сервисе стала явью. Я сам так делал и люди вокруг (Киев) по конференциях тоже ( даже вот такое придумали: https://github.com/spiral/roadrunner)
Мне кажеться, что вся шумиха шла из лагерей php, node, возможно Python.
Го отлично подходит к таким проектам как микросервис
Лично мне, как пользователю Го только в качестве маленького микросервиса с малий зоною ответственности дженериков не надо.
Хотя на дотнет и котлин я им очень рад :)
У всех есть митинги, всем нужно отойти выпить кофе или еще что. С тех пор, даже burndown почти совпадает (оценка в сторипоинтах) и за 4 года никто не жаловался.
Есть техники позволяющие не хранить сессию на стороне сервера. Недавно читал, как сесии хранят в Json Web Token. Думаю далеко не один способ существует для организации чистого stateless
Хмм. Похоже на «Все счастливые семьи счастливы одинаково, каждая несчастливая семья несчастлива по-своему». Как раз где-то на Хабре недавно даже статья проскакивала.
это конечно хорошо, но не всегда компания продуктовая. В out-source/out-stuff Project Manager может никак не влиять на видение продукта. И в таких проектах запросто может не быть отдельного Product Owner`а. Да и в продуктовой компании порою нету ни PO ни BA (как правило в мелких по размеру компаниях). В таких случаях, как раз возможно принятие роли PO каким-то PM`ом так как скорее всего именно он общаеться с клиентом/маркетом/бизнесом. В етом нет ничего плохого.
Они предварительно договариваются с руководством, что получать деньги будут лично от бухгалера на руки.
<sarcasm/>
1. В примере БМПО связан уровень доступа к данным и уровень бизнес-логики
2. БМПО спроектировано плохо:
«Когда клиент отправляется в магазин, он держит товар/товары и отправляет их в кассу, чтобы купить их.Это не ответственность клиентов, чтобы сказать, может ли он купить свои товары, это ответственность сопутствующего лица в кассе.»
Оригинал:
blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/#comment-205
особенно когда на улице 7.2 XD
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
habrahabr.ru/post/275841
А к теме что сложного, вот неплохие статьи:
habrahabr.ru/post/120471
eax.me/caching-is-hard