Раскрытие состояние объекта действительно нарушает инкапсуляцию. Объект предоставляет поведение, и скрывает состояние. Именно поэтому в некоторых языках программирования интерфейсы позволяют декларировать только методы, но не свойства.
Мысль заключается в том, что геттеры/сеттеры предоставляют доступ к состоянию, но не предоставляют поведения. Т.е. придают объектам свойства структур данных, образуя собой объекты-гибриды, недостатки которых хорошо раскрыл Robert C. Martin в своей книге «Clean Code».
Посмотрите, как устроены правильные OO-языки (Smalltalk, Objective-C, Ruby и т.д.). Объекты общаются посредством сообщений. Интерфейс — это протокол взаимодействия. Геттеры/сеттеры никакого взаимодействия не осуществляют, и в большинстве случаев (разумеется, не всегда) просто воплощают Code Smell под названием Feature Envy.
Посмотрите письма Alan Kay, того самого, кто и провозгласил термин OOP:
«I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).» (Alan Kay)
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.» (Alan Kay)
Собственно, упомянутая oxidmod статья именно об этом. Письма Alan Kay можно найти в интернете, два наиболее важных из них я цитировал здесь. Кстати, статья по ссылке тоже посвящена этому вопросу, только уже на уровне паттерна «Event Sourcing».
Скажу честно, в нашей команде таких проблем не бывает. Мы используем значительную часть методик XP (Экстремального Программирования), и поэтому все новички у нас быстро подтягивают свой квалификационный уровень до среднего командного уровня. Разумеется, это работает только в том случае, если в команде присутствуют разработчики (хотя бы один) с хорошим опытом в проектировании.
На ревью мы не тратим время на борьбу мнений, — обычно проблему можно классифицировать по одному из известных каталогов Code Smells (обычно используем каталог Роберта Мартина), или же проблема основана на субъективном мнении и может быть проигнорирована.
Мы не указываем как и что исправить, — мы просто даем линку на нужный метод исправления по каталогу www.refactoring.com/catalog. Если разработчику требуется дополнительная информация — он просто смотрит номер страницы книги по ссылке (каждый метод рефакторинга имеет номер страницы), открывает книгу на нужной странице, и получает всю необходимую информацию.
В корпоративной культуре у нас 5 книг являются обязательными для прочтения каждым разработчиком:
«Design Patterns: Elements of Reusable Object-Oriented Software» by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
«Patterns of Enterprise Application Architecture» by Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford
«Refactoring: Improving the Design of Existing Code» by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
«Clean Code: A Handbook of Agile Software Craftsmanship» by Robert C. Martin
«Code Complete» by Steve McConnell
Кроме перечисленного, инструкторы и менеджеры должны освоить несколько книг Бека по XP. Это как минимум. На практике, для опытных разработчиков, список литературы намного шире.
Если абстракции текут, значит, инкапсуляция не выполняет своей функции по защите абстракций) Так всегда бывает когда нет должного внимания к качеству инкапсуляции.
У автора, безусловно, есть неплохой потенциал писать грамотные статьи, но боюсь, что в данном конкретном случае его статья еще больше запутывает и без того непонятную для многих тему качества кода.
По поводу влияния памяти автор сказал совершенно верно, в основе качественного кода лежит магическое число семь.
Но… проблема умных людей в программировании действительно существует. Хорошо раскрывает эту тему Кент Бек в книге «Экстремальное программирование». Особенно это хорошо заметно в России, где алгоритмический аспект программирования часто превосходит коммерческий аспект сопровождаемости программы.
На самом деле, если «умному человеку» дать немного знаний по экономике разработки ПО, а книга Бека является лучшим пособием по этому вопросу, то проблема исчезает.
Интерфейс — это декларирование поведения и способ управления сложностью. В хорошей программе разработчик не должен открывать реализацию. Он открывает файл с интерфейсами, и ему все должно стать понятным.
Сложность метода измеряется количеством его обязанностей. Данный пример, конечно же прост. И во многом благодаря паттерну Repository. Каждый кто хоть раз в жизни прочитал PoEAA, знает, что этот паттерн отвечает за сокрытие деталей реализации доступа к данным. Кроме того, мне не нужно смотреть его реализации для того чтобы понять, что никаких дополнительных обязанностей (проверку прав и т.п.) он не выполняет.
Все верно. Если интерфейсы ни о чем не говорят, и разработчик вынужден подсматривать реализацию, то проектирование плохое. Программа должна читаться, а не пониматься. Просто потому, что в процессе написания кода разработчики 90% времени читают программу, и плохая читаемость на 90% влияет на темпы разработки.
верно, — «Of course, you can do a better job if you have more tools in your toolbox than if you have fewer, but it is much more important to have a handful of tools that you know when not to use, than to know everything about everything and risk using too much solution.» (Kent Beck)
Agile — это и есть способ командной работы, причем, не нуждающийся в рекламе… Я обсуждаю Ваше утверждение о том, что командная работа — это сказки.
Вероятно, случай с талантливым Риком (а это, как мне рассказывали, описан реальный эпизод) прошел мимо Вашего внимания. Ок, есть не менее интересный эпизод касательно команды, талантов и лидеров. Я лишь слегка модифицировал оригинальный текст.
A boy went fly-fishing for the first time in the Idaho panhandle.
After a fruitless, sweaty day in pursuit of brook trout, he and his friends headed for home. After half an hour of stumbling through dense trees, they realized they were lost. The boy started to panic—fast breathing, tunnel vision, chills. Then someone suggested a plan—they would walk uphill until they hit a logging road they knew was up there. Instantly, the panic disappeared.
Вопрос, кто здесь лидер, кто здесь талант, есть ли здесь команда и какова ее роль, и кого из персонажей Вы персонально взяли бы в свою команду?
В технической среде не может быть никакого лидера без авторитета. А авторитет в технической среде достигается знаниями, продемонстрированными на практике. Иначе получится Рик-2.
> Рекомендую почитать
Я ценю Ваше беспокойство о моем графике чтения. Смею Вас заверить, он расписан на два года вперед, а с уже прочтенным (причем, прочтенным на Английском) списком литературы Вы можете ознакомиться по ссылке. Я искренне надеюсь, что Ваш совет «почитать» не голословен, и Вы так же, с удовольствием, похвастаетесь не только способностью раздавать советы, но и личными практическими достижениями в Ваших же советах.
Вы конечно, имеете право на любое мнение. Но когда Вы противопоставляете свое мнение мнению Кента Бека, ученику Уорда Каннингема, учителю Мартина Фаулера, автору первой (и по сей день — самой эффективной) Agile методологии XP, автору TDD, автору рефакторинга, другу Эрика Гаммы, человеку, внесшему большой вклад в развитие паттернов проектирования и создавшему самые эффективные команды разработчиков на планете, то как Вы думаете, кому больше поверят? Вам, человеку, признавшемся в неспособности создавать эффективные команды (за исключением «сачков» и «равняющихся на отстающих»), или Кенту Беку?
Из Ваших слов явствует только то, что вы никогда не работали по Agile, и даже не понимаете его смысла. Иначе расскажите пожалуйста, кому Вы отводите роль лидера в XP-команде? Ни инструктор, ни администратор для этой роли не подходят. Тимлидов — нет. Есть ревизор, но опять — мимо.
> Для проекта уровня «Миссия невыполнима»
Вы снова продемонстрировали полное незнание Agile. Ни про экономику разработки ПО, ни про минимизацию рисков, ни про раннюю обратную связь, вы, похоже, никогда не слышали. Ибо проектов «Миссия невыполнима» в Agile не может быть в принципе.
> Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.
Опять же, в Agile проектирования как такового нет. Это не Waterfall. Проектирование там делается через рефакторинг. Делается всеми, каждым членом команды. Поэтому нет и архитектора (в этом он и отличается от инструктора, — инструктор не принимает решений). Вы об этом бы знали, если бы хоть раз прошли хотя бы по одной моей ссылке, вместо того, чтобы усердно демонстрировать нам всем здесь Вашу талантливость.
Я мог бы с Вами согласиться, если бы Вы использовали слово «менеджер» вместо слова лидер. Действительно, мне приходилось наблюдать, как смена топ-менеджмента и бездарное управление уничтожили отличную команду менее чем за месяц.
Но… если Вы знаете что такое истинный Agile, особенно в его натуральном виде — Extreme Programming, и хоть раз в жизни работали по нему, то Вы понимаете, что в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду. Настоящий Agile без команды невозможен.
По опыту скажу, что найти в команду готового специалиста — практически нереально. Основная задача отбора — оценить насколько быстро человек сможет подтянуться до среднего уровня команды. Остальное зависит от того, насколько у Вас в команде эффективны совместные методики разработки (формальные инспекции, парное программирование и пр.).
«One team that used formal inspections reported that inspections quickly brought all the developers up to the level of the best developers (Tackett and Van Doren 1999).» (Steve McConnell)
Делая акцент на индивидуальный талант, можно легко попасть в ситуацию описанную в статье "Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом". Разумеется, вина была не в Рике, а опять, же в менеджменте, который полагал, что для успеха достаточно иметь в команде одного «таланта». И Рик — действительно был талантливым парнем, только с недостатком знаний. Он оперировал огромным уровнем сложности (и никто не мог с ним в этом сравниться), просто потому, что не знал, что хорошая архитектура как раз и заключается в устранении этой сложности.
Командная работа это нечто из области коллективного секса
Ну… если так подходить к командной работе, то может тогда персональная талантливость и первостепенна… Не знаю… Я только XP (Agile) пробовал, а там без «Collective Ownership» — никак.
Совершенно верно. Главный императив разработки ПО — управление сложностью. А кто не согласен, тот льстит себе, и думает что у него неограниченный размер черепа (если немного перефразировать известное выражение Дейкстры). Вот главный фундамент качественной архитектуры: число семь.
Молодой человек, конечно, далековат от истины. Но Вы, Naglec, схватили его суждения не за тот хвост). Потому что именно здесь он имеет кое-какие шансы так говорить.
Вообще говоря, существует логика приложения, и бизнес-логика, которая, в свою очередь, разделяется на application-specific(dependent) бизнес-логику и, собственно, предметную бизнес-логику (извиняюсь за тавтологию).
Предметная бизнес-логика — это логика уровня предметных (Domain) моделей. В данной статье предлагается не разделять подвиды бизнес-логики, и все засовывать в сервисы.
А в таком случае, срабатывает принцип, изложенный Мартином Фаулером:
Гораздо легче ответить на вопрос, когда слой служб не нужно использовать. Скорее всего, вам не понадобится слой служб, если у логики приложения есть только одна категория клиентов, например пользовательский интерфейс, отклики которого на варианты использования не охватывают несколько ресурсов транзакций. В этом случае управление транзакциями и выбор откликов можно возложить на контроллеры страниц (Page Controller, 350), которые будут обращаться непосредственно к слою источника данных. Тем не менее, как только у вас появится вторая категория клиентов или начнет использоваться второй ресурс транзакции, вам неизбежно придется ввести слой служб, что потребует полной переработки приложения.
The easier question to answer is probably when not to use it. You probably don’t need a Service Layer if your application’s business logic will only have one kind of client say, a user interface and its use case responses don’t involve multiple transactional resources. In this case your Page Controllers can manually control transactions and coordinate whatever response is required, perhaps delegating directly to the Data Source layer. But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning. («Patterns of Enterprise Application Architecture» Martin Fowler)
Специалист должен полагаться на знания, а не на ощущение персональной талантливой исключительности. Для охарактеризования специалиста лучше подходит слово «компетентность».
«Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетентных специалистов своего поколения.» (Уильям Джеймс)
«Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью.» (Дейкстра 1972)
Командной работе нужно учить. Вот что говорит по этому поводу Кент Бек:
«It’s hard to collaborate. Our whole education system is tuned to individual achievement. If you work with someone on a project, the teacher calls it cheating and punishes you. The reward systems in most companies, with individual evaluations and raises (often cast as a zero sum game), also encourages individual thinking. You will likely have to learn new people skills, interacting as closely with your team as you will in XP.» («Extreme Programming Explained» by Kent Beck)
Молодые специалисты часто устраивают соревнования умом в кодовой базе, разгоняя уровень ее сложности. На самом деле они тем самым демонстрируют собственную некомпетентность, потому что:
«Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.» (Steve McConnell)
«Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.» (Edsger W. Dijkstra)
Ну и если человек на самом деле талантлив, то он направит свои усилия не на то чтобы оторваться от толпы и продемонстрировать свою исключительность, а на то, чтобы сделать команду лучше:
"… it encourages communication. I like to think of the analogy of a pool of water. When an important new bit of information is learned by someone on the team, it is like putting a drop of dye in the water." (Kent Beck, XP)
Понять эту статью можно только с позиции опыта. Могу ее добавить цитаты известных авторитетов на тему простоты и проблемы умных людей. Еще по теме статья М.Фаулера Is Design Dead?.
> ACID только на уровне документа, насколько я понимаю примерно так-же, как у монги.
Тогда, боюсь, что это не ACID, а «Transactions at the single-document level are known as
atomic transactions». Есть еще термин BASE (Basically Available, Soft state, Eventual
consistency) в противовес ACID.
Блокировать всю таблицу ради atomic transactions не нужно, оптимистической блокировки более чем достаточно. Все-таки пессимистическая блокировка существенно влияет на уровень параллелизма.
Но если Вы замахнулись на поддержку JOIN, тогда ACID будет уместным. Но при этом вы поставите крест на возможностях шардинга (CAP-теорема). Есть небольшая книжечка, всего в 150 страниц, «NoSQL Distilled» by M.Fowler, которая кратко и очень доходчиво рассматривает все эти вопросы. Только не читайте русский перевод этой книги, он ужасен, и нередко искажает смысл оригинала.
> Если быть точным, в мире NoSQL, как правило, нет операции Join в чистом виде
Ну, в этом и заключается смысл NoSQL хранилищ. Они ориентированны для работы в условиях шардинга (за исключением некоторых, например, графовых). А поскольку в условиях шардинга невозможно обеспечить ACID (в силу CAP-теоремы), то возник вопрос организации транзакций. Поэтому границами транзакций в NoSQL стали границы агрегата (композитной структуры объектов), что вписывается в распределенную модель хранения информации (и удовлетворяет DDD). Джойны по этой же причине обычно не поддерживаются (что компенсируется поддержкой вложенных объектов).
Кстати, я не заметил, как автор решает проблему параллельного доступа к данных (транзакций). Возможно я этот момент упустил, поэтому пробежался по статье повторно, но так и не нашел. А этот момент очень важный в условиях «100К RPS».
Поскольку в NoSQL границы транзакции совпадают с границами агрегата, там достаточно оптимистической блокировки. Совсем другое дело возникает при поддержке JOIN. В таком случае, следует как-то предотвратить чтение несогласованных данных. А способ реализации транзакций существенно влияет на уровень параллелизма (потому и существует четыре уровня ACID транзакций).
Автор решал совсем другую задачу, нежели решают NoSQL. И хотя термин NoSQL использовать можно в порядке исключения, как это делают, например, графовые БД, но этот термин заметно искажает назначение БД. По этой причине, например, вы не встретите термина NoSQL в документации IndexedDB.
Интересно было бы услышать характеристики используемого диска. И, в целях чистоты эксперимента, было бы интересно рассмотреть вариант монтирования файловой системы тестируемых БД в RAM.
Не столь важно React или Angular, но RxJs для фронтенда, действительно, более удобный чем Redux/Flux/etc., потому что он позволяет работать с классическими моделями предметной области. Реактивные потоки использовались в dojo начиная еще с 2010 года (кстати, dojo2 тоже собирается переходить на RxJs). Безусловно, Redux/Flux имеет право на существование, но фронтенд — не совсем то место, где разновидности реализаций «Event Sourcing» паттерна могут полноценно проявить свои достоинства.
Мысль заключается в том, что геттеры/сеттеры предоставляют доступ к состоянию, но не предоставляют поведения. Т.е. придают объектам свойства структур данных, образуя собой объекты-гибриды, недостатки которых хорошо раскрыл Robert C. Martin в своей книге «Clean Code».
Посмотрите, как устроены правильные OO-языки (Smalltalk, Objective-C, Ruby и т.д.). Объекты общаются посредством сообщений. Интерфейс — это протокол взаимодействия. Геттеры/сеттеры никакого взаимодействия не осуществляют, и в большинстве случаев (разумеется, не всегда) просто воплощают Code Smell под названием Feature Envy.
Посмотрите письма Alan Kay, того самого, кто и провозгласил термин OOP:
Собственно, упомянутая oxidmod статья именно об этом. Письма Alan Kay можно найти в интернете, два наиболее важных из них я цитировал здесь. Кстати, статья по ссылке тоже посвящена этому вопросу, только уже на уровне паттерна «Event Sourcing».
На ревью мы не тратим время на борьбу мнений, — обычно проблему можно классифицировать по одному из известных каталогов Code Smells (обычно используем каталог Роберта Мартина), или же проблема основана на субъективном мнении и может быть проигнорирована.
Мы не указываем как и что исправить, — мы просто даем линку на нужный метод исправления по каталогу www.refactoring.com/catalog. Если разработчику требуется дополнительная информация — он просто смотрит номер страницы книги по ссылке (каждый метод рефакторинга имеет номер страницы), открывает книгу на нужной странице, и получает всю необходимую информацию.
В корпоративной культуре у нас 5 книг являются обязательными для прочтения каждым разработчиком:
Кроме перечисленного, инструкторы и менеджеры должны освоить несколько книг Бека по XP. Это как минимум. На практике, для опытных разработчиков, список литературы намного шире.
По поводу влияния памяти автор сказал совершенно верно, в основе качественного кода лежит магическое число семь.
Кстати, слово refactoring происходит от математического слова факторить (фактор), т.е. декомпозиция. Декомпозиция — как способ управления сложностью, чтобы детали реализации рассматриваемой обязанности не превышали это число 7.
Но… проблема умных людей в программировании действительно существует. Хорошо раскрывает эту тему Кент Бек в книге «Экстремальное программирование». Особенно это хорошо заметно в России, где алгоритмический аспект программирования часто превосходит коммерческий аспект сопровождаемости программы.
На самом деле, если «умному человеку» дать немного знаний по экономике разработки ПО, а книга Бека является лучшим пособием по этому вопросу, то проблема исчезает.
P.S.: автор действительно молодец.
Вероятно, случай с талантливым Риком (а это, как мне рассказывали, описан реальный эпизод) прошел мимо Вашего внимания. Ок, есть не менее интересный эпизод касательно команды, талантов и лидеров. Я лишь слегка модифицировал оригинальный текст.
Вопрос, кто здесь лидер, кто здесь талант, есть ли здесь команда и какова ее роль, и кого из персонажей Вы персонально взяли бы в свою команду?
> Рекомендую почитать
Я ценю Ваше беспокойство о моем графике чтения. Смею Вас заверить, он расписан на два года вперед, а с уже прочтенным (причем, прочтенным на Английском) списком литературы Вы можете ознакомиться по ссылке. Я искренне надеюсь, что Ваш совет «почитать» не голословен, и Вы так же, с удовольствием, похвастаетесь не только способностью раздавать советы, но и личными практическими достижениями в Ваших же советах.
Вы конечно, имеете право на любое мнение. Но когда Вы противопоставляете свое мнение мнению Кента Бека, ученику Уорда Каннингема, учителю Мартина Фаулера, автору первой (и по сей день — самой эффективной) Agile методологии XP, автору TDD, автору рефакторинга, другу Эрика Гаммы, человеку, внесшему большой вклад в развитие паттернов проектирования и создавшему самые эффективные команды разработчиков на планете, то как Вы думаете, кому больше поверят? Вам, человеку, признавшемся в неспособности создавать эффективные команды (за исключением «сачков» и «равняющихся на отстающих»), или Кенту Беку?
Из Ваших слов явствует только то, что вы никогда не работали по Agile, и даже не понимаете его смысла. Иначе расскажите пожалуйста, кому Вы отводите роль лидера в XP-команде? Ни инструктор, ни администратор для этой роли не подходят. Тимлидов — нет. Есть ревизор, но опять — мимо.
> Для проекта уровня «Миссия невыполнима»
Вы снова продемонстрировали полное незнание Agile. Ни про экономику разработки ПО, ни про минимизацию рисков, ни про раннюю обратную связь, вы, похоже, никогда не слышали. Ибо проектов «Миссия невыполнима» в Agile не может быть в принципе.
> Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.
Опять же, в Agile проектирования как такового нет. Это не Waterfall. Проектирование там делается через рефакторинг. Делается всеми, каждым членом команды. Поэтому нет и архитектора (в этом он и отличается от инструктора, — инструктор не принимает решений). Вы об этом бы знали, если бы хоть раз прошли хотя бы по одной моей ссылке, вместо того, чтобы усердно демонстрировать нам всем здесь Вашу талантливость.
Но… если Вы знаете что такое истинный Agile, особенно в его натуральном виде — Extreme Programming, и хоть раз в жизни работали по нему, то Вы понимаете, что в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду. Настоящий Agile без команды невозможен.
По опыту скажу, что найти в команду готового специалиста — практически нереально. Основная задача отбора — оценить насколько быстро человек сможет подтянуться до среднего уровня команды. Остальное зависит от того, насколько у Вас в команде эффективны совместные методики разработки (формальные инспекции, парное программирование и пр.).
«One team that used formal inspections reported that inspections quickly brought all the developers up to the level of the best developers (Tackett and Van Doren 1999).» (Steve McConnell)
Делая акцент на индивидуальный талант, можно легко попасть в ситуацию описанную в статье "Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом". Разумеется, вина была не в Рике, а опять, же в менеджменте, который полагал, что для успеха достаточно иметь в команде одного «таланта». И Рик — действительно был талантливым парнем, только с недостатком знаний. Он оперировал огромным уровнем сложности (и никто не мог с ним в этом сравниться), просто потому, что не знал, что хорошая архитектура как раз и заключается в устранении этой сложности.
Вообще говоря, существует логика приложения, и бизнес-логика, которая, в свою очередь, разделяется на application-specific(dependent) бизнес-логику и, собственно, предметную бизнес-логику (извиняюсь за тавтологию).
Предметная бизнес-логика — это логика уровня предметных (Domain) моделей. В данной статье предлагается не разделять подвиды бизнес-логики, и все засовывать в сервисы.
А в таком случае, срабатывает принцип, изложенный Мартином Фаулером:
Тут, правда, есть нюансы, но я не хочу перегружать этот комментарий, если интересно, то после данной цитаты я их приводил в этой статье по проектированию Сервисного Слоя.
Командной работе нужно учить. Вот что говорит по этому поводу Кент Бек:
Молодые специалисты часто устраивают соревнования умом в кодовой базе, разгоняя уровень ее сложности. На самом деле они тем самым демонстрируют собственную некомпетентность, потому что:
Ну и если человек на самом деле талантлив, то он направит свои усилия не на то чтобы оторваться от толпы и продемонстрировать свою исключительность, а на то, чтобы сделать команду лучше:
Всю информацию сюда не впихнуть, если кому интересно, то "How to quickly develop high-quality code. Team work."
Тогда, боюсь, что это не ACID, а «Transactions at the single-document level are known as
atomic transactions». Есть еще термин BASE (Basically Available, Soft state, Eventual
consistency) в противовес ACID.
Проблему согласованности и атомарности данных Монга выносит на уровень приложения в виде «Two Phase Commits», как об этом говорит документация.
Блокировать всю таблицу ради atomic transactions не нужно, оптимистической блокировки более чем достаточно. Все-таки пессимистическая блокировка существенно влияет на уровень параллелизма.
Но если Вы замахнулись на поддержку JOIN, тогда ACID будет уместным. Но при этом вы поставите крест на возможностях шардинга (CAP-теорема). Есть небольшая книжечка, всего в 150 страниц, «NoSQL Distilled» by M.Fowler, которая кратко и очень доходчиво рассматривает все эти вопросы. Только не читайте русский перевод этой книги, он ужасен, и нередко искажает смысл оригинала.
Ну, в этом и заключается смысл NoSQL хранилищ. Они ориентированны для работы в условиях шардинга (за исключением некоторых, например, графовых). А поскольку в условиях шардинга невозможно обеспечить ACID (в силу CAP-теоремы), то возник вопрос организации транзакций. Поэтому границами транзакций в NoSQL стали границы агрегата (композитной структуры объектов), что вписывается в распределенную модель хранения информации (и удовлетворяет DDD). Джойны по этой же причине обычно не поддерживаются (что компенсируется поддержкой вложенных объектов).
Кстати, я не заметил, как автор решает проблему параллельного доступа к данных (транзакций). Возможно я этот момент упустил, поэтому пробежался по статье повторно, но так и не нашел. А этот момент очень важный в условиях «100К RPS».
Поскольку в NoSQL границы транзакции совпадают с границами агрегата, там достаточно оптимистической блокировки. Совсем другое дело возникает при поддержке JOIN. В таком случае, следует как-то предотвратить чтение несогласованных данных. А способ реализации транзакций существенно влияет на уровень параллелизма (потому и существует четыре уровня ACID транзакций).
Я не хочу затрагивать вопрос о том, что это влечет за собой способ организации клиентского кода (двухфазные транзакции и т.д.).
Отдельно хочу затронуть тему самого термина NoSQL.
«The original call [NoSQL Meetup] for the meetup asked for “open-source,
distributed, nonrelational databases.» (NoSQL Distilled by M.Fowler)
Одним из критериев NoSQL является "Designed to run on large clusters".
Автор решал совсем другую задачу, нежели решают NoSQL. И хотя термин NoSQL использовать можно в порядке исключения, как это делают, например, графовые БД, но этот термин заметно искажает назначение БД. По этой причине, например, вы не встретите термина NoSQL в документации IndexedDB.
Интересно было бы услышать характеристики используемого диска. И, в целях чистоты эксперимента, было бы интересно рассмотреть вариант монтирования файловой системы тестируемых БД в RAM.