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

[Bobkov]

Цитата:

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

То что модуль ERP должен быть самодостаточным доменом - это на самом деле золотая идея. Те же микро-сервисы на уровне модулей ERP.

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

[Pavel]

Цитата:

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

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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