B>Толк это вещь сложная, неопределенная и непонятная. Проще говорить что Domain Model по определению вообще независит от реализации .

я конечно понимаю, что знание какого либо языка (даже UML) не обязательно для описания процессов происходящих в жизни, буть то тех-процессы, бизнес-процессы, то что описывает автоматизируемую систему, в случае автоматизации чего-либо, но ведь это не архитектура ПО.
И безусловно из вашей модели предметной области ну никак однозначно програмную систему построить нельзя, без промежуточных этапов проектирования. А знания языка, ОС, и прочего на этапе проектирования для реализации по-моему просто необходммы... Как вы будете проектировать 3D реадктор скажем, не зная о сушествовании OpenGL и DirectX, а также их особенности, или как вы будете проектировать не зная что в C++ возможно множественное наследование, а в Object Pascal нет, и даже наследование интерфейсов не возможно множественное. Модель модели рознь, и моё мнение таково что модель должна быть построенна так чтобы максимально описывать объект с минимальными затратами на её создание. Я не уверен что описание бизнес-процессов в производстве удобнее представить в виде UML, и затем демонстрировать это управляющему производством или президенту автоматизируемой компании... или вы их UML обучать будете...

B>>>1. Чтобы сначала увидеть лес, а потом интересующие меня деревья.

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


B>>>ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной???

1) взять документацию по системе. А если вам нужно внедрение в систему или переработка, взять книги по SmallTalk, изучить Smalltalk.


M>>Значит надо взять архитектора, который знает SmallTalk.
B>Да гдеж его взять-то милого ... в нашей деревне нету таких

см (1).

p.s. Я не утверждал что использовать UML не возможно или нельзя, я говорил что пользоватся средствами создания и поддержки UML-проектов крайне не удобно, перенося это на язык я говорил что UML (как методологией) пользоваться также не удобно. Безусловно ей пользуются, потому что лучшего нет, хотя сомнительно ибо карандаш-бумага иногда всё таки выразительней и понятней для всех участников, особенно небольшой команды. В больших работать не довелось и спорить я не буду на эту тему. Я просто глубоко уверен что можно создать средство значительно удобнее UML, но к сожалению до сих пор не создано, вероятно потому что одни считают его вовсе не нужным, другие свято верят в его идеалистичность.