Здравствуйте, Gaperton, Вы писали:

G>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.

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

Например, у нас есть правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.

С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.

Здравствуйте, Gaperton, Вы писали:

G>Если MS SQL можно легко заменить, это будет означать, что правила проектирования (архитектура) таковы, что сервер базы данных не важен. В этом случае правила будут звучать по другому, и все. Ими будет явно запрещено напрямую обращаться к БД. Важнее это или не важнее — совершенно не важно. Суть архитектуры — в самом наличии правил, а не в в том, как именно они выглядят.

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

Например, рассмотрим правила, гласящие, что код, относящийся к пользовательскому интерфейсу надо помещать в модуль «UI», код бизнес логики в модуль «BL» и т.д. В случае с .NET, например, эти правила, определяющие распределения кода по сборкам, не формируют архитектуру и не являются архитектурно значимыми, так как мы сможем перераспределить код по сборкам другим способом очень дешево. При этом, если мы почитаем описание архитектуры этого проекта (если оно есть), то там наверняка будут описаны модули и то, какой код в этих модулях содержится.

С другой стороны. Недавно слышал здесь историю, которая мне очень понравилась. Люди решили сделать себе классные автотесты, которые через UI тестируют продукт в режиме black box, полностью эмулируя действия пользователей. Нашли хорошую библиотеку, с помощью которой это можно делать легко и удобно и с энтузиазмом принялись писать тесты. Все было хорошо до тех пор, пока тестов не стало много. После этого начали возникать ситуации, когда некоторые фичи не реализовывались только из-за того, что при их реализации сломается слишком много автотестов, починка которых окажется слишком дорогой. То есть наличие black-box тестов стало архитектурно-значимым фактором (архитектурой), который стал влиять на реализуемость тех или иных продуктовых фич. И это при том, что тесты практически не влияли на код самого продукта, так как они эмулировали действия конечного пользователя. В результате получили такую вот неожиданную архитектуру.