Единость приложения - это не хорошо.

[ax_mct]

Цитата:

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

Делить можно и не разбивая на отдельные программы - программа может состоть из модулей.

Если это отсоединяемые и независимые модули, способные работать автономно, то это Модуль. То есть независимая программа которая присоединяется и отсоединяется.
То что мы часто называем модулями - это просто функциональные области. То что часть обьектов принадлежит этой функциональной области, не делает их "модулем" в общем смысле, это скорее наш сленг. Обратите внимание MS использует сейчас слово "functional area".
Монолит он и есть монолит как его не раскрашивай на квадратики.

[egorych]

Цитата:

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

В едином приложении то же количество соединений и их единость проявляется лишь в том что они свалены в один системный блок.

Ну это зависит от того, кто делает - почему бы все проводки не "сваливать" в 1 кучу, а накладные в другую?

Цитата:

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

Когда делим то сложность уменьшается

С какого это перепуга? Ну поделили 1Ц на 38 модульков - Бухгалтери, торговля, персонал ... и то? Надежность стала выше? Да вот фиг там - постоянные заморочки в обмене, то туда не принимает, то от туда не приходит. В Аксапте почему-то нет таких проблем.

[belugin]

Цитата:

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

Если это отсоединяемые и независимые модули, способные работать автономно, то это Модуль. То есть независимая программа которая присоединяется и отсоединяется.

Неа в понятие модуля не входит способность работать автономно. Это просто кусок у которого есть отдельнве интерфейс и реализация.

With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces. Often modules form a directed acyclic graph (DAG); in this case a cyclic dependency between modules is seen as indicating that these should be a single module. In the case where modules do form a DAG they can be arranged as a hierarchy, where the lowest-level modules are independent, depending on no other modules, and higher-level modules depend on lower-level ones. A particular program or library is a top-level module of its own hierarchy, but can in turn be seen as a lower-level module of a higher-level program, library, or system.

When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are written separately so that, when composed together, they construct the executable application program. Typically these are also compiled separately, via separate compilation, and then linked by a linker. A just-in-time compiler may perform some of this construction "on-the-fly" at run time.

[ax_mct]

Цитата:

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

Неа в понятие модуля не входит способность работать автономно. Это просто кусок у которого есть отдельные интерфейс и реализация.

Это да, но я о Модуле с большой буквы
То есть не сильно много толку от модулей с которыми нельзя как с отдельными приложениями.

Вполне можно сказать что у модулей в AX есть отдельный интерфейс и отдельная реализация.
Толку то.

Для меня модуль это

Модуль — функционально завершённый узел радиоэлектронной аппаратуры, оформленный конструктивно как самостоятельный продукт.

Модуль (космонавтика) — автономно управляемая часть космического корабля (например, модуль МКС).

https://ru.wikipedia.org/wiki/%D0%9C...83%D0%BB%D1%8C

[ax_mct]

Цитата:

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

С какого это перепуга? Ну поделили 1Ц на 38 модульков - Бухгалтери, торговля, персонал ... и то? Надежность стала выше? Да вот фиг там - постоянные заморочки в обмене, то туда не принимает, то от туда не приходит. В Аксапте почему-то нет таких проблем.

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

[belugin]

Цитата:

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

Вполне можно сказать что у модулей в AX есть отдельный интерфейс и отдельная реализация.
Толку то.

Как раз для понимания/снижения сложности совершенно не важно как технологически комбинируются части - главное что есть интерфейс и реализация - то есть части можно понимать раздельно ("что" и "как").

[macklakov]

Цитата:

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

Это да, но я о Модуле с большой буквы

Да хоть с большой, хоть с маленькой. Технологически без разницы.
Смысл модульности в том, чтобы для ГК в СНГ использовать модуль от 1С, а для остальных подразделений, стандартную ГК от Microsoft, ГК от Oracle или ГК от SAP. Чтобы модуль для склада выбирать из 5 вариантов, среди яростно конкурирующих поставщиков. И чтобы порог входа на рынок для конкурентных решений был низкий.
Тогда получится воспроизвести феномен PC, где клиент сам может выбирать и комбинировать из множества вариантов доступных на рынке. Где создалась ситуация в которой огромное количество R&D команд работают над развитием технологии в целом. И это дает такую скорость эволюции, что ее называют не иначе как "компьютерная революция". Кроме того, из-за "поздней" отверточной компоновки возникла высокая степень кастомизации под нужды конкретного клиента. Т.е. не надо будет больше убеждать клиента что "продукт хороший, это у вас бизнес практики не зрелые"

[ax_mct]

Цитата:

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

Как раз для понимания/снижения сложности совершенно не важно как технологически комбинируются части - главное что есть интерфейс и реализация - то есть части можно понимать раздельно ("что" и "как").

Понимание программиста - это конечно хорошо.
А вот внедрение независимых модулей как блоков c Agile да еще и паралельно, их независимое тестирование и независимый деплоймент - это таки да. Модульность.