«Мега» объект промышленного приложения

Под промышленным здесь я имею в виду Enterprise, а мега — то, на что часто бизнес объекты становятся похожими. На разных блогах по программированию часто сравнивают обычное программирование и программирование для Enterprise. Я решил пофантазировать на тему содержимого и свойств — этого самого объекта. В качестве пояснений я использую C#, но сама идея не зависит от используемого языка — поддерживающего ООП.

Одиночный объект

Я допускаю, что в зависимости от языка и используемых библиотек, объект обрастет дополнительными классами (хранилище для сущностей, класс методов наращивания (Extension methods), классы сравнения (EqualityComparer), различные правила преобразований), которые я сознательно совмещу с самим объектом для простоты обзора.

• Хранение объектов. Над объектом должны быть доступны так называемые CRUD-операции (create-создать, read-прочитать, update-обновить, delete-удалить).
• Проверка правильности  (Validation). Поля объектов проверяются на соответствие бизнес правилам во время сохранения или отправления формы.
• Операции над объектом — это собственно действия, которые можно совершить над объектом: проверить пароль пользователя, отобразить детали на странице, выполнить задачу (в случае если объект — это задача (Task) или команда(Command)).
• Контроль доступа (ACL) — определяет, кто имеет доступ к объекту, каким его свойствам или операциям.
• Преобразования (Serialization) — позволяет преобразовать объект в другой тип хранения или обратно (преобразовать в XML, JSON, последовательность байтов). Разве что объекты созданные в JavaScript можно преобразовать в JSON без дополнительных усилий.
• Контроль версий и логирование (Revision &Log) — сохранять предыдущие изменения объекта с целью возможности их восстановления, а также выявление пользователя — изменившего объект.
• Элементы синхронизации — в зависимости от сложности синхронизации поля могут быть разными. В простейшем случае — это дата создания (CreationDate) и  дата последней модификации (ModificationDate).
• Поисковая индексация (Search Indexing) — индексация полей объекта для последующего поиска.
• Модель событий (Event model) — возможность подписаться на события объекта. Например реализация интерфейсов INotifyPropertyChanged и INotifyPropertyChanging.
• Запланированные операции (Scheduled operations) — Отложенные операции до наступления определенного времени.

Список объектов и связи

В подавляющем большинстве случаев Enterprise решение использует базу данных, по этому этот раздел ложится на плечи базы и обслуживающего ее программного слоя.

• Групповая выборка — фильтрация, сортировка и агрегация. Если свойства объекта хранятся в базе данных как поля, с этим проблем возникнуть не должно.
• Объединение (Association) — связи один-к-одному (one-to-one), один-ко-многим (one-to-many), многие-ко-многим (many-to-many).
• Операции над группами объектов (Batch processing) — вообщем, это операция над каждым объектом в списке. Следует избегать блокировки доступа к хранилищу во время работы с большим количеством объектов.
• Классификации и отношения (Classification & Relation) — существует много разнообразных способов классификации и отношений. Простейший пример: дерево таксономических элементов, позволяющих связывать между собой один (классификация) или несколько (отношение) элементов.
• Модель событий (Event model) — события о групповых операциях или изменениях в группе.
• Спусковой крючок (Trigger) — запуск групповых операций на событие. Например: очистка кэша при изменении объекта, оптимизация поискового индекса при загрузке программы.

Архитектура

Архитектура должна учитывать особенности взаимодействия объектов из списка требований. Например — работу с сессией (особенно в распределенных приложениях) и транзакциями, точки проверки соответствия и доступа и так далее. Операции над объектом, обычно вообще не учитываются как свойство определенного объекта, а «размазаны» по коду. Немаловажен и вопрос производительности. По этому, данный список — это следствие архитектуры, а не ее основа.