Трехслойная архитектура приложений, основанных на использовании баз данных

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

перевода системы на модель функционирования «клиент-сервер», разработка параллельно нескольких интерфейсов к системе, в том числе, и Web-интерфейса);
четкая структурированность бизнес-логики;
Любая большая система, основанная на использовании БД, должна отвечать этим требованиям, а если быть точнее, то уровень качества проектирования этой системы во многом зависит от того, насколько система отвечает вышеперечисленным требованиям

3 слоя:

Слой представления (или «вид», “View Layer”)-охватывает все, что имеет отношение к общению пользователя с системой;
Слой источника данных(“Data Source Layer”)- предоставление интерфейса необходимых операций взаимодействия внешних систем(как правило слоя бизнес логики) с источником данных ;
Слой логики домена (бизнес-логика или логика предметной области, “Domain Layer”)-описывает основные функции приложения, предназначенные для достижения поставленной перед ним цели;

и тестирование каждого из слоев;
позволяет изменять структуру, а иногда даже полностью заменять один из слоев, не изменяя при этом другие слои.
Возможность разделения мест функционирования слоев на физическом уровне. Полная интеграция 3х-слойной архитектуры приложения с моделью клиент/сервер.

script);
модель предметной области (Domain Model);
модуль таблицы (Table Module).

разработчиками;
удачно сочетается с простыми схемами организации взаимодействия со слоем источника данных(Data Source Layer);
определяет четкие границы транзакции.

Бизнес-логика в этом случае описывается набором процедур, по одной на каждую (составную) операцию, которую способно выполнять приложение
Преимущества подхода:

сети взаимосвязанных объектов, каждый из которых представляет некую осмысленную сущность предметной области. каждый объект наделяется только функциями, отвечающими его природе
Недостаток подхода:

Если прежде вы не пользовались моделью предметной области, процесс обучения может принести немало трудностей, когда в поис­ках нужных функций вам придется метаться от одного класса к другому.
Преимущество подхода:
освоившись с методом, разработчик получает в свое распоряжение множество приемов, позволяющих описывать возрастающую сложность бизнес-логики гибким путем с минимальными временными затратами

и модели предметной области

«Вычисление зачтенного договора» с помощью сценария транзакции

одному классу на каждую таблицу базы данных, и единственный экземпляр класса содержит всю логику обработки данных таблицы.
Преимущество подхода:

решение позволяет сочетать данные и функции для их обработки и в то же время эффективно использовать ресурсы реляционной базы данных.
Недостаток подхода:
модуль таблицы не позволяет использовать многие технологии (например, наследование, стратегии и другие объектно-ориенти­рованные типовые решения), которые применяются в модели предметной области для уточнения структуры логики

таблицы
(Table Module)

Сценарий транзакции
(Transaction Script)

Сложность бизнес-логики

С
Т
О
И
М
О
С
Т
Ь
Р
Е
А
Л
И
З
А
Ц
И
И

бухгалтерского учета с внедрением возможностей экономического моделирования и прогнозирования;
Система будет работать в локальной сети с топологией «звезда», используя модель клиент-сервер. 1 сервер, ориентировочное число активных клиентов -70. Средняя активность клиентов – выше среднего.