skyANAЧто-то на схеме нет внешних систем :)
ну вон же EDI, там либо документы хранятся (они оттуда поступают, либо их надо скачать), либо данные для сверки, и как вариант там может и не быть веб-клиента - тогда по идее некуда будет пихнуть web worker

yabsшеф кстати вообще настаивает на вот таком варианте
по идее она самое православное, только мне не хочется делать Мэппинг из Persistence объектов в Business сначала в Backend'е
и потом еще раз в ASP.NET
не будет такого двойного маппинга, бэк-енд отдает всем потребителям (и принимает от них) модели, которые внутри него мапятся один раз (но в обе стороны) на сущности ORM например

бэк-енд как уже сказали - можно в виде WebApi, а можно и wcf отдельный и только на публичные методы для EDI

а тут опять же, если EDI сам документы присылает - это одно, если надо их скачивать оттуда - другое

yabsтак вопрос не в том, нужен Worker или нет, а в том, как хостить модуль обработки(я его обозвал BACKEND'ом)
модуль обработки хостить как сервис (web-api или wcf)
можно сделать так, чтобы сайт тоже работал с сервисом, но там надо лезть глубже

но нужно еще средство вызова обработки, которое не давало бы сбой, тут три варианта:
1. не делать фоновой обработки вообще (если позволяет время ожидания и скорость алгоритмов и отклика внешних систем) - тогда как только документ поступает каким либо образом в систему - сразу же идет проверка
2. сделать планировщик на сервере (виндовая служба, либо воспользоваться внешним сервисом - hangfire)
3. сделать планировщик на клиенте (web worker), как предложили - но тут мне лично не понятно, а что если файл придет ночью, никто не работает в веб приложении - как воркер запуститься?

yabs,
теоретически можно обойтись только одним набором моделей - типа объекты предметной области, их же использовать в качестве контрактов для сервисов и уровень сериализации/десериализации будет на границе между бэк-ендом и потребителями (EDI/ASP.NET)

эти же сущности можно замапить на таблицы БД через ОРМ, я видел однажды очень хороший пример - довольно сложные сущности, но с помощью замысловатых маппингов с тонкой настройкой это все отражалось в таблицы БД через nHibernate

но на практике постоянно возникают всякие проблемы, то с контекстом ORM, то сущности становятся слишком перегруженными, то с отображением на UI (когда одна сущность имеет несколько экранов с немного разным набором полей для разных ролей пользователей), и т.п.

поэтому делают два слоя - объекты (сущности) предметной области (они же маппятся на БД) и модели для отображения (они же контракты для сервисов), маппинг соответственно между сущностями и моделями, наружу отдают модели, третий по идее лишний