Разделение платформы и бизнес логики решается путем организации классов в соответствующие уровни приложения – уровень разрабатываемый пользователем и уровень метаданных.

Между этими уровнями, в архитектуре платформы, есть каналы управления интерфейсом и управления данными.

Принято следующее правило именования сборок:
C1 – компоненты WinForms от GrapeCity
C2 – системные компоненты платформы
C3 – сборки, относящиеся к прикладному разрабатываемому решению

Здесь, для примера, библиотеки, разработанные пользователем:

• C3.Accounting.Module — модули объектов и модули проведения
• C3.Accounting.Win — формы объектов (справочников, документов, отчетов и обработок)

Библиотеки, созданные Дизайнером:

• C3.JustMoney.Model — прикладные объекты (справочники, документы, регистры)
• C3.ModelManager — менеджер доступа к прикладным объектам модели
• C3.ModuleManager — менеджер доступа к модулям прикладных объектов
• C3.JustMoney.Form — базовые классы форм прикладных объектов
• C3.FormManager — менеджер форм прикладных объектов

JustMoney, Accounting, Docflow – имя бизнес логики, может быть любым.

Состав библиотек решения зависит от их следующего функционального назначения:

В структуре конфигурации самым обобщенным элементом является схема.

Внутри каждой схемы расположены объекты модели конфигурации (справочники, документы и т.п.).

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

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

Разрабатывая прикладное решение, разработчик работает с объектами модели, например справочник «Контрагент» или  документ «РасходнаяНакладная».

Соответственно, объекты модели принимают в значения полей эти же типы, а не идентификаторы и прочие простые типы языка программирования, например «РасходнаяНакладная.Контрагент = Покупатель», где «Покупатель», это экземпляр типа «Контрагент».

Конструирования прикладных типов модели происходит в менеджере модели.

Платформой обеспечивается гарантированное выполнение предопределенных методов в модулях объектов и модулях проведения при записи или проведении экземпляров объектов, вне зависимости от контекста приложения, windows-приложение или web-приложение.

Примеры таких предопределенных методов – BeforeWrite, AfterWrite, Post, UnPost и т.п.

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