Давайте посмотрим на это с точки зрения эволюции проектов разработки программного обеспечения "Enterprise":
- Начните с очень простого, хорошо организованного и, возможно, нового приложения с небольшими проблемами обслуживания (еслиты счастливчик).Программисты могут быть недавними выпускниками, но система молодая или достаточно чистая, они могут быть эффективными и быстро реагировать на запросы об изменениях.Большая часть кода базы данных может использовать хранимые процедуры.В этом не участвует администратор БД, нет официальной спецификации или дорожной карты.
- Приложение растет.Часто требуется, чтобы несколько программистов работали в одних и тех же частях системы одновременно.Новые градиенты открывают систему управления исходным кодом, чтобы помочь им обмениваться кодом между несколькими программистами и отойти от хранимых процедур в пользу n-уровневого дизайна или ORM, чтобы упростить версию кода базы данных.Это работает хорошо, пока каждая отдельная функциональная область достаточно изолирована.Теперь администратор базы данных может начать помогать настраивать запросы.Спецификации до сих пор нет, но может быть дорожная карта высокого уровня или список пожеланий.
- Это в конечном итоге превращается во взаимосвязанную систему приложений, которая выросла органически, а не по дизайну.Запросы на изменение становятся сложными, поскольку изменения в одной области имеют незначительные последствия в других.Чтобы решить эту проблему, когда несколько приложений обращаются к одной и той же базе данных и нуждаются в совместном использовании общей и сложной бизнес-логики, программисты обращаются к сервис-ориентированной архитектуре (веб-сервисам).Старые данные и бизнес-уровни анализируются, объединяются и реорганизуются в общий набор веб-сервисов.Большинство программистов теперь даже не знают, как подключиться к своей базе данных - это разрешено делать только тем, кто работает с основными службами, и даже они, как правило, оставляют любой фактический SQL команде DBA.Если модульное тестирование еще не используется, оно теперь обнаруживается как часть настройки системы непрерывной интеграции или системы отслеживания проблем.
- Система продолжает расти, но бизнес растет еще быстрее.Вещи обычно работают;Качество хорошее, производительность не отличная, но все же приемлемая.Теперь определенно есть трекер спецификаций и проблем;на самом деле, невозможно сделать что-либо, для чего с ним не связан номер для отслеживания.Проблема в том, что скорость изменения слишком медленная.Уровни процесса между программистами и приложениями не позволяют им идти в ногу с бизнесом экономически эффективным способом.Кто-то открывает гибкие методы.
- Вернитесь к первому шагу.
Если серьезно, история выше помогает установить контекст для веб-служб и понять проблемы, для которых они предназначенырешать.Из этого контекста видно, что веб-сервисы действительно охватывают как уровень данных, так и уровень бизнеса.Целью сервисного уровня является обеспечение совместного использования общего набора правил между несколькими приложениями.Исключение бизнес-уровня из вашего сервиса дает программистам возможность написать свой собственный бизнес-код для каждого приложения, и это, в первую очередь, непродуктивно для цели использования сервисов.
Тем не менее, это возможночто вещи оказываются сложенными в слоях, где у вас есть сервисы необработанных данных, которые являются частными для определенных частей бизнеса, и эти «сырые» сервисы, в свою очередь, используются для создания нисходящих сервисов, которые составляют слой бизнес-правил.Трудно точно сказать, чем на самом деле занимается бизнес.Тем не менее, я чувствую, что этот уровень разъединения встречается реже.