Наскільки важливо зробити рівень обслуговування?

Я почав створювати додаток у 3 шари (DAL, BL, UI) [він в основному обробляє CRM, деякі звіти про продажі та інвентар].

Колега сказав мені, що я повинен перейти до схеми службового шару, що розробники прийшли до схеми обслуговування зі свого досвіду, і це кращий підхід до проектування більшості програм. Він сказав, що таким чином буде набагато легше підтримувати додаток у майбутньому.

Особисто я відчуваю, що це просто робить речі складнішими, і я не міг бачити від цього великої користі, яка б це виправдала.

У цього додатка є додатковий невеликий частковий інтерфейс, який використовує деякі (але лише декілька) функцій настільних додатків, тому я знайшов копіювання коду (але не дуже багато). Просто через деяке дублювання коду я б не перетворював його на орієнтований на сервіс, але він сказав, що я повинен використовувати його все одно, тому що в цілому це дуже хороша архітектура, чому програмісти так захоплюються послугами ??

Я спробував перейти на Google, але я все ще розгублений і не можу вирішити, що робити.

У книзі Мартіна Фаулера "Шаблони архітектури підприємства" зазначено:

Простіше відповісти на питання, мабуть, коли його не використовувати. Напевно, вам не потрібен рівень обслуговування, якщо бізнес-логіка вашої програми матиме лише один тип клієнта - скажімо, користувальницький інтерфейс - і відповіді на використання випадків не включають в себе кілька ресурсів транзакцій. [...]

Але як тільки ви передбачите клієнта другого типу або другого транзакційного ресурсу, який використовує відповіді на використання випадків, він сплачує проектувати в Сервісному шарі з самого початку.

Переваги, які надає Службовий рівень, - це те, що він визначає загальний набір операцій із застосуванням, доступних для різних клієнтів, і координує відповідь у кожній операції. Якщо у вас є додаток, який має більше ніж один вид клієнтів, який споживає свою бізнес-логіку і має складні випадки використання, пов'язані з кількома транзакційними ресурсами, - має сенс включати рівень обслуговування з керованими транзакціями.

З CRM, продажами та інвентаризацією буде багато випадків використання типів CRUD, які майже завжди є індивідуальною перепискою з операціями рівня обслуговування. Відповіді на створення, оновлення або видалення об’єкта домену повинні бути скоординовані та трансакціоновані атомним шляхом операціями рівня обслуговування.

Ще одна перевага наявності рівня обслуговування - це те, що він може бути розроблений для локального або віддаленого виклику або обох - і надає вам гнучкість для цього. Цей шаблон закладає основу для послідовної реалізації бізнес-логіки програми та виклику цієї логіки різними клієнтами послідовно. Це означає, що ви також зменшуєте / видаляєте дублювання коду, оскільки ваші клієнти діляться однаковими загальними послугами. Ви також можете потенційно знизити витрати на обслуговування - як коли змінюється ваша логіка бізнесу, вам (як правило) потрібно змінити сервіс, а не кожного з клієнтів.

Підсумовуючи це, добре використовувати службовий шар - більше того, я думаю, у вашому прикладі ви вказали, як це звучить, як у вас є кілька клієнтів ділової логіки.

Додавання рівня обслуговування, оскільки ви оцінили ідею та зробили висновок про її найкращий підхід: добре

Додавання сервісного шару, тому що це роблять усі класні діти: погано

Якщо ваша кишка каже, що вона вам не потрібна, то не робіть її.

Одне з найбільш невтішних розробок у світі програмування протягом останніх 10 років - це те, що воно набридло орієнтується на моду, коли люди слідкують за тенденціями та бандажами, ніби взуття цього сезону. Не потрапляйте в цю пастку. Тому що в наступному сезоні «всі» будуть говорити вам, що ви мали б це спроектувати по-іншому.

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

Є багато факторів, які входять у рішення про створення рівня обслуговування. У минулому я створював службові шари з наступних причин.

1. Код, який потребує повторного використання декількома клієнтами.
2. Бібліотеки сторонніх організацій, для яких у нас ліцензії обмежені.
3. Сторонні сторони, які потребують точки інтеграції до нашої системи.
4. Централізація дублюваної логіки бізнесу.

Випадок 1: Ви створюєте базову функціональність, яку потрібно використовувати безлічі різних клієнтів. Службовий рівень вбудовує функціональні можливості для різних клієнтів, щоб скористатися наданою функціональністю прямо з коробки.

Випадок 2: Ви, як правило, кодуєте хост у просторі додатків, але використовуєте сторонні бібліотеки, на які у вас обмежені ліцензії. У цьому випадку у вас є ресурс, який ви хотіли б використовувати скрізь, але лише обмежена їх кількість. Якщо ви розміщуєте його за сервісом, то вся ваша організація може використовувати його зі своїх додатків без необхідності купувати ліцензію на кожен окремий хостинг.

Випадок 3: Ви будуєте функціонал для того, щоб треті сторони спілкувалися з вами. У своєму прикладі ви можете встановити кінцеву точку інвентаризації, щоб дозволити постачальникам передавати вам повідомлення про вхідні поставки товару.

Випадок 4: Ви широко проаналізували ваше кодове підприємство і виявили, що окремі команди створили одне і те ж (просто реалізовано трохи по-іншому). За допомогою сервісного шару ви можете вибрати найкращий підхід, і тепер ви можете реалізувати процес однаковий у всіх командах, запросивши їх в службу. Ще одна користь для централізації логіки - це коли виявляються помилки. Тепер ви можете розгорнути виправлення один раз, і всі клієнти отримують переваги одночасно.

Все, що говориться, є потенційні негативи для рівня обслуговування.

1. Додає складність системи. Якщо раніше у вас була лише одна програма для налагодження, тепер у вас є дві. Проблеми з виробництвом вимагають перевірити налаштування клієнтських програм, налаштування додатків служб або проблеми зв'язку між коректно налаштованими клієнтськими програмами та серверними програмами. Це може бути складним, якщо ви ніколи цього не робили.
2. Один момент відмови. Якщо у вас відмова від обслуговування, це впливає на всіх клієнтів. Якщо код не розгортається таким чином, ризик може бути меншим (хоча є способи його зменшити).
3. Версію можна зробити важче. Якщо у вас є одне додаток, що використовує сервіс, що розгортає інтерфейс, зміни можуть бути здійснені одночасно між ними. Коли у вас є кілька клієнтів, ви повинні керувати тим, хто перебуває на V1, хто на V2, і координувати видалення V1 (коли ви знаєте, що всі оновились до V2).

Головний момент - це не завжди сунучка, щоб зробити систему орієнтованою на вашу систему. На мій досвід, зазвичай це гарна ідея (я прагну структурувати додатки таким чином), але це не автоматичне рішення. Наприкінці дня вам потрібно зважити плюси і мінуси і прийняти рішення, яке підходить для вашої ситуації.

Більшість шарів обслуговування, які я бачив, - це повний безлад. Служби, як правило, мають багато різних методів, 1500 LOC - не рідкість. Різні методи не мають нічого спільного, але вони діють код. Це призводить до високої зв'язку , низької згуртованості . Він також порушує OCP , оскільки щоразу, коли потрібна нова операція, вам доведеться змінювати код замість розширення бази коду. Теоретично можливий добре побудований рівень обслуговування, але я цього ніколи не бачив на практиці.

CQRS вирішує ці проблеми та заважає вам створювати один із таких процедурних службових рівнів.

Додавання інтерфейсу (рівень обслуговування - це тип інтерфейсу) вимагає часу. Хороший вимагає багато часу для розробки та тестування. Дуже важливо правильно це зробити з першої спроби, оскільки його зміна пізніше розбиває всіх клієнтів. Крім того, врахуйте, що ви, мабуть, не знаєте, що повинно бути в цьому інтерфейсі, поки у вас не буде другий клієнт з дещо іншими потребами. Підтримка сервісу - сам по собі нескінченний проект.

У більшості організацій, якщо ви звертаєтесь до спонсора вашого бізнесу і запитуєте їх: "Чи хочете ви, щоб інші відділи отримали користь (повторне використання) цієї системи, яку ми розробляємо з вашим бюджетом?" вони будуть сміятися над вами. Спершу попросіть його працювати за спонсора вашого бізнесу, а потім почніть обертатись, використовуючи цей код (у власний час вашого відділу).

Якщо ви фактично знаєте, що функціональність, про яку ви пишете сьогодні, буде повторно використана декількома різними клієнтами сервісу, то розгляньте питання про розробку рівня обслуговування з першого дня. Якщо ви не впевнені, або у проекті вже багато невідомих, спочатку знайдіть щось просте, і розділіть його на обслуговування та клієнта пізніше, якщо у вас є час та бюджет. Набагато простіше отримати інтерфейс обслуговування прямо з першої спроби, коли ви почнете працювати з робочою системою.

PS Якщо ви працюєте на Java, Джошуа Блох має багато фантастичних порад щодо інтерфейсу у всій своїй книзі «Ефективна Java».

Я погоджуюсь з тобою. Не потрібно включати ще один шар, якщо ви використовуєте один інтерфейс.

DAL, BL та UI / Controller - це гарне поєднання для розробки програми. Якщо ви плануєте використовувати один інтерфейс, готувати зайвий шар не потрібно. Включення ще одного шару в додаток лише збільшує зусилля / час на розробку.

Інша схема - використання декількох інтерфейсів у вашій програмі, добре мати сервісний рівень для обробки інтерфейсів у цьому випадку.

Переповнення стека: обговорення схеми сервісного шару

Я б заперечував, що ваш BL - це ваш рівень обслуговування. Центральне місце, де сидить ваша логіка бізнесу. Це повинна бути DLL, яка може використовуватися будь-яким, що потребує цієї логіки. Тоді ви можете покласти шар веб-api поверх того, якщо ваш додаток матиме різні інтерфейси користувача.