Mocking the interactions between all classes forces you to create mocks that return other mocks (that might return yet other mocks). You have to mock out all the data pathways in the interaction; and that can be a complex task. This creates two problems.
- The setup code can get extremely complicated.
- The mocking structure become tightly coupled to implementation details causing many tests to break when those details are modified.
The need to mock every class interaction forces an explosion of polymorphic interfaces. In statically typed languages like Java, that means the creation of lots of extra interface classes whose sole purpose is to allow mocking. This is over-abstraction and the dreaded "design damage".
“Mock across architecturally significant boundaries, but not within those boundaries.”
Наконец, ещё одно замечание касается того, что в ходе выполнения транзакции согласованность не требуется. В нашем примере, списание и зачисление будут, скорее всего, двумя разными подоперациями и между их выполнением внутри транзакции будет видно несогласованное состояние системы. Однако не нужно забывать, что при выполнении требования изоляции, никаким другим транзакциям эта несогласованность не будет видна.
Тем самым эта промежуточная несогласованность является скрытой.
This appetite for more data, is pushing the boundaries of traditional RDBMS systems and forcing companies to research alternative data stores.
...
From customer/subscriber information, to movie metadata, to monitoring stats, it’s all hosted in Cassandra.
In most of our uses, Cassandra is the source of truth database. There are a few legacy datasets in other solutions, but are actively being migrated.
MySQL и Oracle, у которых якобы "проблемы с горизонтальным масштабированием"
One team even built a sharded RDBMS cluster, with every node in the cluster being replicated twice. This solution is also very complex to manage. We are currently working to migrate to C* for that application.
Очень смешно.
<hr>. Наверное было бы здорово, если бы вы могли таким декларативным способом описывать не только линию, а всё что угодно. Например написав<calendar></calendar>вы получили бы полноценный функциональный календарь. Естественно этот компонент еще необходимо создать или взять готовый. Весь фронтенд собирается как конструктор из набора таких компонентов.Это можно сделать и на jquery. Но на jquery как правило получается спаггети-код, где бизнес-логика перемешивается вместе с DOM. В итоге бизнес-логику становится сложно тестировать и поддерживать. Angular позволяет спроектировать программу таким образом, чтобы отделить бизнес-логику от работы с DOM за счет двухстороннего связывания шаблона с компонентом.
Да, подключается на стороне клиента. У вас возникло непонимание, потому что код на angular принято писать на языке typescript. Браузеры этот язык не поддерживают и как следствие вы очевидно не можете запустить такую программу напрямую в браузере. Следовательно нужно скомпилировать код на typescript в javascript. Node.js здесь используется как инструмент, чтобы выполнять такое преобразование и на выходе получить готовый билд, который сможет исполняться в браузере. На продакшен вы будете выкатывать эти билды, а для разработки использовать исходники на typescript.
Если всё это пока слишком сложно, можете попробовать начать с vue.js. Идея абсолютно такая же, но избавляет вас от необходимости думать обо всем этом. Вы просто берете знакомый вам javascript и начинаете писать. Порог входа максимально упрощен. Люди осваивают vue также просто, как и jquery.