Оver-engineering - "зачем так сложно?" - Мортира Карл

[Pavel]

Цитата:

Сообщение от Bobkov

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

Минимум связей по данным не получится, потому фундаментом единного приложения (то что называют - РЕШЕНИЕ) является БАЗА ДАННЫХ, в отношении которой действуют законы нормализации (см. нормальные формы БД).

Разбить модули на независимые сервисы можно, но разделение данных нарушит нормализацию, вместо одной БД возникнет столько, сколько сервисов. Тогда возникнут новые проблемы... не менее интересные (кто занимался синхронизацией и репликацией распределенных данных, тот сталкивался).

[ax_mct]

Цитата:

Сообщение от Bobkov

Мне кажется, важнее всего не то, что модуль можно вынуть и заменить на что-то, а то что этот модуль вообще выделен как сущность обособленная, то есть имеющая минимум связей с другими модулями. Не только связей по коду, но и связей по данным. Эти связи должны быть максимально четко специфицированы и их должно быть невозможно случайно нарушить. Если выделить в системе такой модуль, то оказывается, что сложность его познания и развития упала на порядок, что собственно и требуется. Можно ли использовать для реализации такой модульности ООП? Наверное, можно в какой-то части. Я бы наверное взял из ООП принцип инкапсуляции и постарался им ограничиться.

Именно что без сквозных связей и сквозной функциональности все легче и понятнее. Декомпозиция это всегда ключ к простоте и пониманию.

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

В то время как ООП нельзя давать в руки адептов это религии в принципе, так как они сокрушат все стенки в доме просто потому что им так лучше видно. Проткнут насквозь все что можно проткнуть.

Поэтому те люди что используют T-SQL для бизнес-логики - они гениальны. Потому как программисты больные на голову - им может не хватать слоев абстракции

[macklakov]

Цитата:

Сообщение от Pavel

Интересно, что же такое пересадили в ГК из GP в АХ, необходимое не ради 'архитектуры', а как часть развития бизнес-приложения... то что модно называть громким словом - РЕШЕНИЕ?!

пс. Чего там так не хватало))))

Можно предположить что цель всех этих телодвижений была в том, чтобы легче было перетаскивать GP клиентов на AX, ибо в US именно GP имела самый большой рынок из линейки Dynamics. По факту, конечно же, стало гораздо сложнее. Бухгалтера довольно безболезнено пересаживались с GP на 2009, ибо сразу понятно что это совсем другая система, со своей логикой. Из-за 2012-й иногда половина отдела увольняется. Т.к. с виду вроде как напоминает GP, но ничего не получается сделать привычным способом. С их точки зрения это не новая продвинутая система в которой надо разбираться чтобы идти в ногу со временим, а это какая-то ужасно изуродованная GP, в которой ничего не работает как надо.