Проект CF становится слишком большим, что делать?
Простая биллинговая система (в дополнение к ColdBox MVC) превращается в приложение для инвентаризации полу-предприятия + инициализации + отслеживания проблем + отслеживания прибыли. Они, кажется, делают свое дело, но у них много общего, включая общий пул клиентов и персонала (логин) и другую смешанную информацию и бизнес-логику.
Как вы держите такую систему модульной? с точки зрения обслуживания, тестируемости и повторного использования?
- одно монолитное приложение? (т.е. новый пакет для базового приложения)
- Модуль ColdBox? не уверен, как сделать его "устанавливаемым" и какие преимущества он дает.
- Java-портлет? понятия не имею, просто мыслить нестандартно
- Архитектура SOA? через вызовы API веб-сервиса?
Любая идея и / или опыт, которым вы хотели бы поделиться?
5 ответов
Перестаньте думать о технологиях (например, Java-порталах, модулях ColdBox и т. Д.) И сосредоточьтесь на архитектуре. Под этим я имею в виду, как вы можете объяснить свою систему наблюдателю. Начните с рисования набора полей на доске, которые представляют каждый элемент - инвентарь, клиенты, отслеживание проблем и т. Д. - и затем используйте линии, чтобы показать взаимодействие между этими системами. Это фокусирует вас на разделении интересов, то есть на группировке, как функциональность. Для начала не беспокойтесь об интерфейсе, вместо этого сосредоточьтесь на алгоритмах и данных.
Если вы говорите о MVC, то этот шаг сосредоточен на модели. С этим завершением завершается сложная часть: изменение кода для соответствия этой диаграмме (то есть модели). Чтобы по-настоящему понять, как должна выглядеть эта модель, я предлагаю прочитать Эрик Эванс (Eric Evans). Цель состоит в том, чтобы прийти к модели, отношения которой управляются путем внедрения зависимостей. Предположительно, это оставляет вас с набором высокоуровневых ХФУ - услуг, если хотите, - с базовыми бизнес-объектами и управлением постоянством. Их отношения лучше всего управляются с помощью своего рода локатора контейнеров / сервисов, который, как мне кажется, у ColdBox есть свой, другим примером является ColdSpring.
Результатом этих усилий является модель, которую можно тестировать на единицу. Независимо от пользовательского интерфейса. Если все это сбивает с толку, я бы посоветовал взглянуть на " Эффективная работа с устаревшим кодом" для некоторых идей о том, как осуществить этот переход.
Как только вы это сделаете, теперь можно подумать о контроллере (например, ColdBox) и связать модель с представлениями через него. Однако внимательно изучите любой контроллер и выберите его из-за некоторых возможностей, которые он приносит в таблицу, которая нужна вашему приложению (пример кеширования приходит на ум). Ваши представления, вероятно, также должны быть переосмыслены, чтобы взаимодействовать с этим новым дизайном, но у вас должна быть система, в которой алгоритмы теперь отделены от пользовательского интерфейса, что упрощает работу представлений.
Реально, вы решаете эту проблему итеративно. Найдите одну систему, которую легко разобрать описанным мною способом, проведите ее по модульным тестам, подтвердите также с людьми и перейдите к следующей системе. Хотя это утомительный процесс, я могу заверить, что это гораздо меньше работы, чем пытаться переписать все, что приводит к катастрофе, если у вас нет очень хорошего набора автоматической проверки заранее.
Обновить
Повторюсь, технология не решит вашу проблему. Продолжение итерации к более сплоченным объектам будет.
Теперь, что касается связанных данных, с ORM вы сделали компромисс, и у монолитных систем есть свои преимущества. Другой подход - дать одному объекту с состоянием ссылку на объект службы другого через DI, чтобы вы могли получить его через него. Это позволит вам смоделировать его с целью модульного тестирования и заменить его аналогичным сервисным объектом и соответствующим объектом для облегчения повторного использования в других контекстах.
С точки зрения решения бизнес-задач (например, бухгалтерского учета) повторное использование - это возникающее свойство, когда вы пишете несколько систем, которые делают примерно одно и то же, а затем выясняете, как обобщать. Редко, если когда-либо, по моему опыту, вы начинаете писать что-то, чтобы решить какую-то бизнес-проблему, которая становится компонентом многократного использования.
Я бы порекомендовал вам разбить приложение на модульные части с помощью модулей ColdBox. Вы также можете исследовать отдельную бизнес-логику на уровне RESTful ColdBox и, таким образом, присоединиться к системе. Опять же, все зависит от ваших требований и потребностей на данный момент.
Модули предназначены для разделения монолитных приложений на более управляемые части, которые могут быть автономными или соединенными вместе.
Я бы посоветовал вам потратить некоторое время на просмотр модулей. Это поможет разделить ваш код на логические функции, сохранив интеграцию с моделью.
Будучи ColdBox, есть множество документов и примеров...
К счастью, проблема, с которой мы здесь сталкиваемся, не уникальна.
Проблема здесь, похоже, не в самом коде или в том, как его разбить на части, а в том, чтобы понять, что вы сейчас находитесь в процессе проектирования и разработки ERP.
Знание того, как лучше всего разработать и вырастить ERP, который логически управляет деталями этой организации, является более глубоким вопросом, на который, я думаю, вы пытаетесь ответить. Сам дизайн и архитектура того, как кодировать это, вытекает из понимания основных функциональных областей, которые вам нужны.
К счастью, мы можем изучить некоторые существующие ERP-системы, которые вы можете использовать, чтобы увидеть, как они решили некоторые из проблем. Существует несколько хороших ERP-программ с открытым исходным кодом, и мне пришло в голову, что это полный цикл установки SAP Business One, который я наблюдал (ERP небольшого и среднего размера, которая обходит проблемы большого SAP).
То, что вы ищете, это увидеть, как другие решают ту же архитектуру ERP, с которой вы сталкиваетесь. По крайней мере, вы получите представление о компромиссах между модуляризацией, где провести черту между модулями и почему.
Как правило, система ERP обрабатывает все, начиная от предложения, до производства (если требуется), до выставления счетов, отгрузки и полученного учета.
ERPS обрабатывают два основных мира:
- Производство товаров
- Доставка услуги
Некоторые предприятия являются фабриками виджетов, другие - предприятиями сферы услуг. Полнофункциональная стандартная ERP будет иметь одну непрерывную цепочку / жизненный цикл "заказа", который обслуживается несколькими шагами.
Если мы прочитаем приблизительный список шагов, которые может охватить ERP, вы увидите те, которые относятся к вам. Это, вероятно, модули, которые у вас есть или должны быть разбиты на ваше приложение. Представьте себе следующие шаги, где каждый является отдельным документом, все связаны с предыдущим в цепочке.
- Lead Generation -> Возможности продаж
- Возможности продаж -> Цитировать / Оценить
- Смета -> Заказ на продажу
- Заказ клиента -> Производственный заказ (создайте его или назначьте кого-нибудь для выполнения работы)
- Производственный заказ -> Заказ на покупку
- Производственный заказ -> Производственное планирование (Что будет построено, когда или Кто, когда?)
- График производства -> Продукция! (Выполнять работу)
- Произведенная услуга / товар -> Корректировка инвентаря - при необходимости преобразуйте любые сырые запасы в готовую продукцию или подготовьте ее к отправке
- Готовые товары / услуги -> Упаковочный лист
- Упаковочные элементы -> Счет-фактура
Системные интеграторы используют необходимые шаги и пропускают те, которые не используются. Это приводит к одной вещи для вашего растущего приложения:
Получите надежную стратегию защиты данных на месте. Убедитесь, что вам удобно, чтобы каждый мог видеть только то, что должен. Предполагая, что это на месте, хорошая идея разбить приложение на основные части. Модули наши друзья. Однако приказ разбить их, скорее всего, окажет большее влияние на то, что вы делаете, чем что-либо еще.
Посмотрите, какие разделы являются общими (отчеты и т. Д.), Которые можно повторно использовать между несколькими приложениями, а какие более специализированы для самого приложения. Функции, которые связаны с самим приложением, вероятно, будут уже более тесно связаны, и вам, возможно, придется обойти это.
Для ERP я всегда предпочитал транзакционный "основной" модуль, который используют все остальные поставщики транзакций (выставление счетов за продвижение процесса, как только он определен).
Когда я преобразовал Lotus Notes ERP из 90-х годов в SAP ERP, приложение Lotus Notes было превосходным, оно обрабатывало все как и должно. Были некоторые мини-приложения, построенные на стороне, которые не были интегрированы как модули, что было главной причиной избавления от него.
Если бы вы переписали приложение сегодня с учетом сегодняшних требований, как бы вы сделали это иначе? Посмотрите, есть ли существенные отличия от того, что у вас есть. Позвольте приложению побороться за ваше внимание, чтобы решить, что в первую очередь нуждается в капитальном ремонте / модульности. ColdBox отлично подходит для модульности, независимо от того, используете ли вы модули плагинного типа или просто используете хорошо разделенный код, вы не ошибетесь, это всего лишь функция времени и денег разработчика, которые могут сделать это.
Первые модули, на которых я собирался / автоматизировал модульное тестирование, являются наиболее сложными программно. Скорее всего, если вы приличный разработчик, вам не нужно от конца до конца модульного тестирования со вчерашнего дня. Начните с самого сложного, перейдите к основным частям приложения, а затем перейдите к другим областям, которые могут держать вас ночью.
Надеюсь, что это помогло! Поделитесь тем, что вы в конечном итоге делаете, если вы не возражаете, если что-то, что я упомянул, нуждается в дополнительном объяснении, напишите мне здесь или в твиттере:) @JasPanesar
Вам нужно избавиться от MVC и заменить его архитектурой SOA, чтобы единственной вещью, соединяющей две половины, были запросы на обслуживание.
Итак, на стороне сервера у вас есть уровни DAO и FACADE. А клиентская сторона может быть MVC или любой другой архитектурой, которую вы хотите использовать, находясь где-то еще. Вы даже можете иметь индивидуального клиента для каждого отдельного бизнеса.
Даже для серверной части вы можете разбить проект на несколько серверов: что общего для всех предприятий, а затем - для всех.