2 tchingiz: Эх, прямо душу погрели ссылкой.

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

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

Ну и наконец: любой серьезный программный продукт, начиная с куда более простых, нежели "полнофункциональная ИС", просто обязан быть реализован модульно, поскольку это единственный на сегодня путь справиться с его сложностью. Те ПП, которые не используют модульный подход, просто разваливаются под собственной тяжестью (вспоминая только вчера упомянутую МВ-шную Основную Задачу). Фактически я полагаю правильным сказать, что для любого ПП можно назвать четкий предел роста, опираясь на данные о его модульности (количестве и качестве модулей).

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

AlexTheRavenА обращение к web-сервису ещё туманней - непонятно, ошибка в процедуре, в web-сервисе или в сети, .....
Это несколько другая тема. Скажем, представьте себе, что Вы вызываете одну и ту же подпрограмму из двух мест, в одном - пользуясь ЯВУ, в другом - из ассемблера. Второе, очевидно, сложнее, потребует больше действий, при этом возможны ошибки (например, переполнение стека). И если посмотреть через линзу Вашего утверждения, вроде как оказывается, что подпрограмма автономна "по-разному" в зависимости от того, кто к ней обращается.

Я бы сказал, автономность - это одно, а технология синхронного либо асинхронного вызова конкретного средства из конкретного средства - совсем другое.

AlexTheRavenЗато чем автономнее модуль тем (по идее) меньше он зависит от других, т.е. веб-сервис на одном узле продолжит работать, даже если все другие "упадут" с ошибкой или "повиснут", скушав все доступные ресурсы. Вопрос - насколько это нужно для каждой конкретной системы.
Это часть автономности, но не вся автономность.

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

Но автономность относится не только к эксплуатации ПП, но и к другим этапам - разработке, внедрению, сопровождению...

AlexTheRavenЦельность и целостность - IMHO не антоним модульности.
Может быть, выбрано неудачное слово, но оно в этом топике используется во вполне определенном смысле. Вы пытаетесь изменить тему обсуждения, при этом заодно перейдя от "цельной" к никем кроме Вас не упоминавшейся "целостной".

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

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