В конечно счете если взять типичную трехслойную архитектуру кода, запретить просачиваться ЛЮБЫМ НЕ БИЗНЕС сущностям в сервис слой(если совсем - то просто запретить импорт всех пакетов, кроме собственных и допустим java.*) и мы получим +- тоже самое.
Тогда сервис слой будет в себе содержать алгоритм, бизнес логику или что там аналитик ставит(последовательность вызовов, преобразований, проверок и т.д.) и все - это будет довольно просто тестируемо. И в таком случае мы любой из слоев можем легко заменить(допустим с хибера перейти на jooq).
И тут пытливый читатель спросит: а как же модули? А я отвечу, что тут начнется то, из за чего это все сложно стартует - чтобы работать с фичами\модулями\ддд и всем остальным, надо чтобы анализ работал над постановкой задач, надо чтобы проект имел функциональную модель(или любую другую) с границами, чтобы повторять модули за этой моделью, иначе со временем реальность разойдется с кодовой базой, появится либо дубли, либо переиспользование адаптеров из других модулей и так далее. Сложно всем будет.
а что такое бизнес логика? если представить, что адаптер реализует сохранение сущности в бд, то бизнес логикой является вызов+аргументы функции адаптера.
Ну и честно сказать, я такие "прокси приложения, которые просто перекладывают" вижу только при старте проекта, а через полгода - в условном сервис слое уже увесистая лапша из вызовов других адаптеров, проверок разнообразных и т.д.
Есть ощущение, если провести декомпозицию будущей системы сверху вниз в том же столетнем idef0, то мы получим:
1) функции системы
2) кол-во связей функций между друг другом
из чего мы можем получить первичную оценку, что, куда и как можно отнести.
И еще нюанс или вопрос: как так получилось, что api появилось до декомпозиции ?
Флаг прочтения есть только у персональных уведомлений. Уведомления отправляются разными экторами в разное время — персональные отправляются системой автоматически, а новостные — по запросу администратора. Они отправляются разным людям — персональные отправляются водителю, создавшему точку, а новостные — всем водителям. Даже методы API для отправки используются разные.
Архитектурные подходы идут по спирали: на одном витке преобладают формальные подходы(uml, паттерны, формализованный подход), на другом витке — неформальные(к которым можно отнести вариаци tdd, user story map знаменитого Jeff Patton). В конечном итоге, как мне кажется, архитектура и в самом деле подбирается под команду(чтобы не переучивать всех на очередной язык разметки unm, bpmn & etc), либо же команда подбирается со знанием нужных архитектурных подходов.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Немного надоедает слышать про копипасту и изменения.
Почему никто не говорит, что код может быть одинаковым, но не копипастой? Для примера, два разных сценария используют условно одинаковый код(допустим, запрос в какую то систему с нужными параметрами)? Я могу сделать "общий" запрос, но, в случае, если одна из систем потребует изменений, а другая - нет, мы рискуем получить какую-нибудь ошибку.
В целом, сам подход, при котором мы в одном месте меняем и все где-то как-то само происходит - таит в себе кучу проблем. Нет уж - дублируйте код, делайте копипасту, пока вы точно не уверены, что понимаете, как работать с "общими" компонентами.
В самом общем случае мы имеем 3 класса: ZooAnimal, ZooKeeper, Food.
В ZooAnimal у нас инкапсулируется метод eat(Food), который внутри себя решает, ест животное это или выбрасывает исключение, что животное сдохло. Чтобы понять, ест ли это животное или нет, можно при создании животного передать список того, что же оно ест. И есть метод - дай мне доступную еду.
В ZooKeeper у нас инкапсулирует метод feed(List<ZooAnimal> animals, List<Food> food), который просто перебирает животных и к каждому подбирает первую попавшуюся еду из списка доступных у животного. Метод поиска еды можно усложить(он в ZooKeeper) сколько угодно - прикрутить расчет и все такое. Но в таком виде он примитивный - дай мне первую попавшуюся еду, которая соответствует еде из списка доступных.
Дальше просто создаем список животных, еду и передаем это все ZooKeeper.
Можно усложнять и добавлять классы, но откуда в этой задаче switch? ООПе же.
Я бы аналитиков заставлял рисовать схемы для себя(для начала) - если получился осьминог, то задачу точно надо упрощать до щупальца. А потом уже презентовал там команде....Да и команде оно не надо...разрабу нужно щупальце, а оно укладывается в понятие сценарий, для которого сложные инструменты обычно только вредят.
Прямо мемуары снежинки.
В конечно счете если взять типичную трехслойную архитектуру кода, запретить просачиваться ЛЮБЫМ НЕ БИЗНЕС сущностям в сервис слой(если совсем - то просто запретить импорт всех пакетов, кроме собственных и допустим java.*) и мы получим +- тоже самое.
Тогда сервис слой будет в себе содержать алгоритм, бизнес логику или что там аналитик ставит(последовательность вызовов, преобразований, проверок и т.д.) и все - это будет довольно просто тестируемо. И в таком случае мы любой из слоев можем легко заменить(допустим с хибера перейти на jooq).
И тут пытливый читатель спросит: а как же модули? А я отвечу, что тут начнется то, из за чего это все сложно стартует - чтобы работать с фичами\модулями\ддд и всем остальным, надо чтобы анализ работал над постановкой задач, надо чтобы проект имел функциональную модель(или любую другую) с границами, чтобы повторять модули за этой моделью, иначе со временем реальность разойдется с кодовой базой, появится либо дубли, либо переиспользование адаптеров из других модулей и так далее. Сложно всем будет.
а что такое бизнес логика? если представить, что адаптер реализует сохранение сущности в бд, то бизнес логикой является вызов+аргументы функции адаптера.
Ну и честно сказать, я такие "прокси приложения, которые просто перекладывают" вижу только при старте проекта, а через полгода - в условном сервис слое уже увесистая лапша из вызовов других адаптеров, проверок разнообразных и т.д.
так я потому и спросил, что есть - полез в апи и там увидел в концепции про ключи идемпотентности. Ну ок, буду ждать тогда - интересно.
А самое интересно про идемпотентность оставили вне статьи?;)
Есть ощущение, если провести декомпозицию будущей системы сверху вниз в том же столетнем idef0, то мы получим:
1) функции системы
2) кол-во связей функций между друг другом
из чего мы можем получить первичную оценку, что, куда и как можно отнести.
И еще нюанс или вопрос: как так получилось, что api появилось до декомпозиции ?
Флаг прочтения есть только у персональных уведомлений. Уведомления отправляются разными экторами в разное время — персональные отправляются системой автоматически, а новостные — по запросу администратора. Они отправляются разным людям — персональные отправляются водителю, создавшему точку, а новостные — всем водителям. Даже методы API для отправки используются разные.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Немного надоедает слышать про копипасту и изменения.
Почему никто не говорит, что код может быть одинаковым, но не копипастой? Для примера, два разных сценария используют условно одинаковый код(допустим, запрос в какую то систему с нужными параметрами)? Я могу сделать "общий" запрос, но, в случае, если одна из систем потребует изменений, а другая - нет, мы рискуем получить какую-нибудь ошибку.
В целом, сам подход, при котором мы в одном месте меняем и все где-то как-то само происходит - таит в себе кучу проблем. Нет уж - дублируйте код, делайте копипасту, пока вы точно не уверены, что понимаете, как работать с "общими" компонентами.
IP и в самом деле сложнее сменить, чем страну.
понятно, описания не будет, а будет просто какая-то воображаемая декомпозиция.
От ООП что-то совсем мало осталось.
В самом общем случае мы имеем 3 класса: ZooAnimal, ZooKeeper, Food.
В ZooAnimal у нас инкапсулируется метод eat(Food), который внутри себя решает, ест животное это или выбрасывает исключение, что животное сдохло. Чтобы понять, ест ли это животное или нет, можно при создании животного передать список того, что же оно ест. И есть метод - дай мне доступную еду.
В ZooKeeper у нас инкапсулирует метод feed(List<ZooAnimal> animals, List<Food> food), который просто перебирает животных и к каждому подбирает первую попавшуюся еду из списка доступных у животного. Метод поиска еды можно усложить(он в ZooKeeper) сколько угодно - прикрутить расчет и все такое. Но в таком виде он примитивный - дай мне первую попавшуюся еду, которая соответствует еде из списка доступных.
Дальше просто создаем список животных, еду и передаем это все ZooKeeper.
Можно усложнять и добавлять классы, но откуда в этой задаче switch? ООПе же.
так у вас то тоже ничего не запрещает разрабу вызвать LocalDateTime.now()? кроме стайлчека..добавить к утилитному классу рестрикт и все.
https://infostart.ru/upload/iblock/330/330b8f0326f48225c8892194f8eb2241.png
Вот вроде довольно простой пример.
А можно краткий пример описания бизнес-процесса в нотации BPM и в том, что описано тут?
Я бы аналитиков заставлял рисовать схемы для себя(для начала) - если получился осьминог, то задачу точно надо упрощать до щупальца. А потом уже презентовал там команде....Да и команде оно не надо...разрабу нужно щупальце, а оно укладывается в понятие сценарий, для которого сложные инструменты обычно только вредят.
Сегодня переезд 2м людям на 4.5к в месяц, часть из которых уйдет на налоги - сомнительна, как по мне.
Что значит навигация идеи отстает от вим? Рефакторинг в виме? Это каким адоном?