QЭффективнее исходить из предположения, что расположенный выше уровень приложения точно знает, какие именно проводки следует сформировать в том или ином случае.

На практике приложение уровнем выше ничего не знает о проводках. Проводки делает back office - бухгалтерия. В автоматизированной ситеме это может быть сервер бухгалтерских проводок, который собирает первичку из OLTP системы front office и по заданным правилам разносит в бухгалтерский OLAP.

Naf,

ты не думал описывать шаблоны в терминах метамодели?

_модexplaВ автоматизированной ситеме это может быть сервер бухгалтерских проводок, который собирает первичку из OLTP системы front office и по заданным правилам разносит в бухгалтерский OLAP.
А при изменении первички все раходится в разные стороны ... Все надо делать в одной системе

Значит ты придумал плохой back office. Придумай хоший, и всё станет пучком.
Кто мешает "при изменении первички" выполнить корректирующие проводки?

_модexplaописывать шаблоны в терминах метамодели?
А что потом с этим описанием делать - транслировать в код ? или на стенку повесить ?

Метамодель определяет правила построения модели (собственно о чём мы тут и говорим). Конечно их можно транслировать в код. Но это будет код не прикладного, а инструментального средства, т.е. средства предназначенного для разработки прикладных моделей, в данном случае систем бух. учёта.

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

_модexplaКто мешает "при изменении первички" выполнить корректирующие проводки?
Вручную ?

Зачем вручную? Автоматически, конечно. Как вариант, берём новую версию первички, разваливаем её на бух. проводки, сравниваем с теми бух. проводками, что уже есть в системе бух. учёта, и на разницу создаём корректирующие проводки, где надо с +, где надо с -. В итоге общая сумма выравнивается (по периодам конечно может быть некрасиво, но как правило не смертельно).

Сам так делал. Сначала бушки от красных строчек в отчёте в обморок падали, но потом смекнули, что на общем фоне это всё равно не видно (если оборот +1000000р., а корректировок на -1000р., то всё равно останется +999000р.), а картина получается ясная и понятная (всё видно), и успокоились.

Конечно может статься так, что лажа большая случилась и за это грозят штрафы или казённый дом. Ну тогда концы в воду придётся руками прятать, или сухарики сушить.

_модexpla Конечно их можно транслировать в код.
Это очень сомнительно. Если что-то можно транслировать в код, то это что-то и есть код, только на другом языке.


Если к понятию трансляции не слишком строго, то смотря чем транслировать. Ведь требование заказчика "хочу Ы,... каждому", обычно рано или поздно транслируется в код.

_модexplaЗачем вручную? Автоматически, конечно.
Это предполагает единую (ну или хотя-бы распределеннную) БД, ч.т.д.


Сервер проводок может брать первичку из OLTP БД и разносить её в БД бухгалтерии.

Распределённость тут не при чём. Обе БД могут находиться на одном узле, но при этом не иметь прямых связей и зависимостей. Тут существенно то, что обе системы со своими БД взаимодействуют как компоненты только через открытые интерфейсы и тем самым изолированы друг от друга.

_модНедостаток всех метамоделей в том, что это не рабочий код.

Даже модель это ещё не рабочий код. Но всё идёт к тому, что код будет создаваться прямо из модели.

_модВ результате лучшая модель - это собственно код программы.

Не факт. Зависит от задачи. Для анализа и спецификации код не лучшее представление. Формально, код требует доказательства того, что он соответствует спецификации. Как правило такое доказательство очень трудоёмко. В свою очередь спецификация должна соответствовать бизнес требованиям.

_модexplaТут существенно то, что обе системы со своими БД взаимодействуют как компоненты только через открытые интерфейсы и тем самым изолированы друг от друга.
SOA ? Плохо это - транзакции не поддерживаются.


Ну при чём тут SOA? SOA это всего лишь частный случай взаимодействия систем. Открые системы и компонентный подход появились за долго до SOA. И в SOA транзакционность можно обеспечить, только придётся поработать.

_модexplaФормально, код требует доказательства того, что он соответствует спецификации.
Да и это на сегодняшний день основная и нерешенная проблема программирования.

Теоретически она вроде как решена, даже языки программирования созданы с поддержкой контрактов.

_модexplaИ в SOA транзакционность можно обеспечить, только придётся поработать.
Может и можно, только вот зачем, если есть распределенные БД, где транзакционность обеспечивает СУБД.

Так нам и распределённая БД не нужна, всё на одном узле под одним экземпляром СУБД можно крутить. Наконец, прикрутить SOA ты придумал, а не я, так сам и разбирайся, зачем.

_модexplaТеоретически она вроде как решена, даже языки программирования созданы с поддержкой контрактов.
Для ее решения выбранный язык программирования должен иметь полностью формализованную семантику, а этого нет для большинтства ЯП. Да и сама спецификация может содержать ошибки - получается замкнутый круг.

Это как, язык без семантики? Что есть языки в которых 2+2 имеет неопределённый смысл? Бывает, конечно, что некоторые понятия не описаны формально в явном виде, но косвенно всё можно определить, или таким языком нельзя пользоваться.

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

Явных успехов удалось добиться в SQL (есть ещё ряд других языков, с которыми в силу специфика рабоне я не сталкивался). Ведь SQL запрос это по сути спецификация требуемого результата, тогда как план выполнения запроса сочиняет и выполняет сама СУБД.