|
AlexsalogSeVaМифический мир "документов" есть только в 1С, где привыкли ехать на телеге впереди сивой кобылы.
Вам вредно о забивать себе голову подобными глупостями, все равно ничего другого не будет.
Цепочка из внешнего воздействия на систему->команда->аггрегирующий домен для оркестровки событий и данных->событие->event sourcing для логирования и возможности восстановить состояние на определенный момент->отдельные с единичной ответственностью, а не в одной большой, вонючей куче обработчики событий, которые могут быть локальные или удаленные, весьма неплохо подходят для многих вариантов. Этот паттерн позволяет существенно упростить логику обработки в достаточно внятном варианте.
А простота она хуже воровства, если нет никакой возможности для маневров в дальнейшем.
Да, кстати про 1С. Параллельная система в компании для которой я делаю программу - это 1С. Так вот у них там бредовый бред с "учетом на основе документов". Например есть такие виды "документов":
- "Накладная б/д" - сие означает, что по этому документу должна быть произведена отгрузка Б ез Д окументов реализации для налогового учета. Пометка б/д в названии документа говорит менеджеру очень многое (этакое зашифрованное, сжатое в аббревиатуру послание) : а) по документу можно отгрузить, но нельзя печатать по нему Счет-фактуру и Накладную, поскольку формы были предоставлены ранее, до отгрузки. б) Данная отгрузка является не полной, есть некий документ (обычная Накладная), содержащий полный список товаров.
- "Счет резерв" - слово резерв означает, что по счету не предполагается реальной отгрузки и даже не предполагается резервирования на складе компании, а всего лишь нужно придержать товар на складе головного предприятия, пока продажники трут терки с клиентом.
- "Счет реализация" - счет, по которому нужно произвести все реальные операции.
Конечно, используется функция "Создать на основании", но суть в том, что недостающий функционал закрывается изобретением подвидов документов, у которых почти все необходимое для работы кодируется в названии и соответствующий порядок обработки и интерпретация данных - полностью ответственность операторов.
Производится многократное дублирование информации, которая размазывается, размывается по различным копиям одного и того же. Также, по причине дублирования, есть определенные проблемы с отчетностью.
Читаю сейчас Фаулера, вот что там написано:
авторГлава 2 Организация бизнес-логики
Рассматривая структуру логики предметной области (или бизнес-логики) приложения, я изучаю варианты распределения множества предусматриваемых ею функций по трем типовым решениям: сценарий транзакции (Transaction Script), модель предметной об¬ласти (Domain Model) и модуль таблицы (Table Module).
Простейший подход к описанию бизнес-логики связан с использованием сценария транзакции — процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других систем. Затем процедура возвращает слою представле¬ния определенные данные, возможно, осуществляя вспомогательные операции для фор¬матирования содержимого результата. Бизнес-логика в этом случае описывается набором процедур, по одной на каждую (составную) операцию, которую способно выполнять при¬ложение. Типовое решение сценарий транзакции, таким образом, можно трактовать как сценарий действия, или бизнес-транзакцию. Оно не обязательно должно представлять собой единый фрагмент кода. Код делится на подпрограммы, которые распределяются между различными сценариями транзакции.
Типовое решение сценарий транзакции отличается следующими преимуществами:
• представляет собой удобную процедурную модель, легко воспринимаемую всеми разработчиками;
• удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений шлюз записи данных (Row Data Gateway) и шлюз таб¬лицы данных (Table Data Gateway);
• определяет четкие границы транзакции.
С возрастанием уровня сложности бизнес-логики типовое решение сценарий транзак¬ции демонстрирует и ряд недостатков. Если нескольким транзакциям необходимо осуще¬ствлять схожие функции, возникает опасность дублирования фрагментов кода. С этим явлением удается частично справиться за счет вынесения общих подпрограмм "за скоб¬ки", но даже в этом случае большая часть дубликатов остается на месте. В итоге прило¬жение может выглядеть как беспорядочная мешанина без отчетливой структуры.
Конечно, сложная логика — это удачный повод вспомнить об объектах, и объектно-ориентированный вариант решения проблемы связан с использованием модели пред¬метной области, которая, по меньшей мере в первом приближении, структурируется преимущественно вокруг основных сущностей рассматриваемого домена. Так, например, в лизинговой системе следовало бы создать классы, представляющие сущности "аренда", "имущество", "договор" и т.д., и предусмотреть логику проверок и вычислений: так, на¬пример, объект, представляющий сущность "имущество", вероятно, уместно снабдить логикой вычисления стоимости.
Выбор модели предметной области в противовес сценарию транзакции — это как раз та смена парадигмы программирования, о которой так любят говорить апологеты объект¬ного подхода. Вместо использования одной подпрограммы, несущей в себе всю логику, которая соответствует некоторому действию пользователя, каждый объект наделяется только функциями, отвечающими его природе. Если прежде вы не пользовались моделью предметной области, процесс обучения может принести немало огорчений, когда в поис¬ках нужных функций вам придется метаться от одного класса к другому.
Различие между двумя рассматриваемыми подходами на простом примере описать довольно сложно, но я все-таки попытаюсь это сделать. Простейший способ состоит в сопоставлении диаграмм последовательностей (sequence diagrams), соответствующих обо¬им вариантам решения одной проблемы (рис. 2.1 и 2.2).
В задаче определения зачтенного дохода от продажи каждого продукта в рамках за¬данного контракта (подробнее это рассматривается в главе 9, "Представление бизнес-логики") алгоритм вычислений зависит от типа продукта. Вычислительный метод дол¬жен распознать тип продукта, применить подходящий алгоритм, а затем создать соответ¬ствующий объект, представляющий значение дохода. (Аспекты взаимодействия с базой данных для простоты здесь не рассматриваются.)
Из рис. 2.1 видно, что все обязанности возлагаются на метод сценария транзакции, полу¬чающий данные от объектов типа шлюз таблицы данных. На рис. 2.2 показано, напротив, несколько объектов, каждый из которых несет ответственность за выполнение своей доли функций, а результат генерируется объектом "Стратегия определения зачтенного дохода".
Ценность модели предметной области состоит в том, что, освоившись с подходом, вы получаете в свое распоряжение множество приемов, позволяющих поладить с возрас¬тающей сложностью бизнес-логики "цивилизованным" путем. Например, с увеличением количества алгоритмов расчета дохода достаточно создавать новые объекты "Стратегия определения зачтенного дохода". При использовании сценария транзакции в аналогичной ситуации пришлось бы добавлять в логику метода дополнительные условия. Если вы на¬столько же неравнодушны к объектам, как и я, то наверняка предпочтете модель предмет¬ной области даже в самых простых случаях.
Стоимость практической реализации модели предметной области обусловлена степе¬нью сложности как самой модели, так и конкретного варианта слоя источника данных. Чтобы добиться успехов в применении модели, новичкам придется затратить немало времени: некоторым требуется несколько месяцев работы над соответствующим проек¬том, прежде чем их стиль мышления перестроится в нужном направлении. После приоб¬ретения опыта работать становится намного проще — в вас даже просыпается энтузиазм. Через все это прошел и я, и все другие, кто так же одержим объектной парадигмой. Впро¬чем, сбросить груз привычек и сделать шаг вперед многим, к сожалению, так и не удается.
Разумеется, каким бы ни был подход, необходимость отображать содержимое базы данных в структуры памяти и наоборот все еще остается. Чем более "богата" модель предметной области, тем сложнее становится аппарат взаимного отображения объектных структур в реляционные (обычно реализуемый на основе типового решения преобразова¬тель данных (Data Mapper)). Сложный слой источника данных стоит дорого — в финансовом смысле (если вы приобретаете услуги сторонних разработчиков) или в от¬ношении затрат времен (если беретесь за дело самостоятельно), но если он у вас есть, считайте, что добрая половина проблемы уже решена.
Существует и третий вариант структуризации бизнес-логики, предусматривающий применение типового решения модуль таблицы; он показан на рис. 2.3.
На первый взгляд это типовое решение очень похоже на модель предметной области: в обоих случаях создаются отдельные классы, представляющие контракт, продукт и за¬чтенный доход. Принципиальное различие заключается в том, что модель предметной об¬ласти содержит по одному объекту контракта для каждого контракта, зафиксированного в базе данных, а модуль таблицы является единственным объектом. Модуль таблицы при¬меняется совместно с типовым решением множество записей (Record Set). Посылая запросы к базе данных, пользователь прежде всего формирует объект множество записей, а затем создает объект контракта, передавая ему множество записей в качестве аргумента (см. рис. 2.3). Если потребуется выполнять операции над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (ID).
Модуль таблицы во многих смыслах представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области. Организация бизнес-логики вокруг таблиц, а не в виде прямолинейных процедур облегчает структурирование и возможность поиска и удаления повторяющихся фрагментов кода. Однако решение модуль таблицы не позволяет использовать многие технологии (скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориенти¬рованные типовые решения), которые применяются в модели предметной области для уточнения структуры логики.
Наибольшее преимущество модуля таблицы состоит в том, как это решение сочетается с остальными аспектами архитектуры. Многие графические интерфейсные среды позво¬ляют работать с результатами обработки SQL-запроса, организованными в виде множества записей. Поскольку решение модуль таблицы также основано на использовании множества записей, открывается возможность выполнения запроса, манипулирования его результатом в контексте модуля таблицы и передачи данных графическому интерфейсу для отображения. Некоторые платформы, в частности Microsoft COM и .NET, поддерживают именно такой стиль разработки.
Рекомендую почитать: Мартин Фаулер. Архитектура корпоративных программных приложений. 2006.
|
