"C# 9 Records as DDD Value Objects" by Vladimir Khorikov
https://enterprisecraftsmanship.com/posts/csharp-records-value-objects/

#DDD

Две превосходные статьи про Культ Карго в программировании:
1. "Культ карго в программировании", Сергей Тепляков
http://sergeyteplyakov.blogspot.com/2013/09/blog-post_24.html
2. "Cargo Cult Software Engineering" by Steve McConnell
https://stevemcconnell.com/articles/cargo-cult-software-engineering/

#Career #Agile #SoftwareDesign #SoftwareDevelopment

"Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined" by Nick Tune
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c

#DDD #Microservices

Еще один комментарий в сторону Uber, на этот раз - от Nick Tune:
"If DDD had clear definitions, maybe Uber wouldn't have created their own definitions."
https://ntcoding.medium.com/my-main-problems-are-c779a6d62da

#DDD #Microservices

📝 "Patterns are the antidote to the suck/rock dichotomy.

There's far too many isolated tweets dispensing architecture advice that ignores context/problem + solutions/benefits/drawbacks. 😢"
- Chris Richardson
https://twitter.com/crichardson/status/1331696743382097920?s=19

#Microservices #SoftwareDesign #SoftwareArchitecture

📝 "✨New educational materials!✨
Today I'm announcing two new, free resources I've written: an 8-lecture course on fundamentals of distributed systems, and a 30-page tutorial on elliptic curve cryptography. https://martin.kleppmann.com/2020/11/18/distributed-systems-and-elliptic-curves.html "
- Martin Kleppmann
https://twitter.com/martinkl/status/1329051710019543041?s=19

P.S.: Если кто не знает, Martin Kleppmann - один из лучших авторов по распределенным системам. Автор "Кабанчика".

The distributed systems course comprises about 7 hours of video and 87 pages of lecture notes. It covers the following topics:
1. Introduction: distributed systems, computer networks, and RPC
2. System models: network faults, crash and Byzantine faults, synchrony assumptions
3. Physical clocks, clock synchronisation, and causality
4. Logical time, broadcast protocols (reliable, FIFO, causal, total order)
5. Replication, quorum protocols, state machine replication
6. Consensus, details on the Raft consensus algorithm
7. Replica consistency, two-phase commit, linearizability, eventual consistency
8. Case studies: collaboration software, Google’s Spanner

#SoftwareDesign #DistributedSystems #SoftwareArchitecture

📝 "The distributed systems course covers many of the fundamental algorithms behind today's apps. It consists of 87 pages of detailed notes (including exercises) https://t.co/5PmH0ESwDh and 7 hours of lecture videos https://t.co/oXvqzaTwrX "
- Martin Kleppmann
https://twitter.com/martinkl/status/1329052185183854593?s=19

#SoftwareDesign #SoftwareArchitecture #DistributedSystems

Мотивирующее фото для тех, кто сетует на нехватку времени и не может прочитать ни одной книги за полгода. Это фото Сергея Теплякова: https://www.instagram.com/p/CGv38kHnotb/?igshid=1nrcey0v5xa75
Который не только прочитал, по моим оценкам, уже более пары сотен технических книг, но и даже успел написать одну книгу, а так же кучу архи-полезных статей у себя в блоге http://sergeyteplyakov.blogspot.com/
Работает он сейчас в Microsoft и живет в США.

Это фото подтверждает слова А.В.Суворова: "Дисциплина - мать победы". У человека или есть дисциплина, и тогда он успевает все, или ее нету, и тогда он не успевает ничего.

#Career

Alexey Zimarev добавил аргументов к посту Nick Tune:
- https://alexey-zimarev.medium.com/i-become-to-believe-that-the-dub-domain-and-bounded-context-and-domain-model-concepts-arent-that-3d75c3861f3c
- https://alexey-zimarev.medium.com/i-see-that-kenny-wrote-almost-exactly-the-same-as-i-did-in-the-previous-comment-19d28142d669
- https://alexey-zimarev.medium.com/indeed-the-relativity-of-core-vs-supportive-vs-generic-in-business-lines-is-often-overlooked-4e70156288c1?source=rss-e500a4698713------2

#DDD #Microservices

C4-Model & Event Storming with ArchiMate, см. "Figure 13: Event Storming Model" of "Agile Architecture Modeling Using the ArchiMate® Language"
- https://publications.opengroup.org/g20e
- https://nicea.nic.in/sites/default/files/Agile_Architecture_Modelling_Using_Archimate.pdf
- https://nicea.nic.in/download-files.php?nid=247

Модель (обратите внимание на то, что автором модели является сам Jean-Baptiste Sarrodie):
- https://community.opengroup.org/archimate-user-community/home/-/issues/8

Archimatetool - бесплатный инструмент, с открытым исходным кодом, который позволяет управлять описанием архитектуры интегрированно, как в problem space, так и в solution space. Причем, осуществлять это коллективно.

Плагин к Archimatetool для коллективной разработки:

coArchi - a plug-in to share and collaborate on Archi models.
- https://github.com/archimatetool/archi-modelrepository-plugin

Описание плагина:
- https://www.archimatetool.com/plugins/#coArchi

Документация к плагину:
- https://github.com/archimatetool/archi-modelrepository-plugin/wiki

Пользовательская документация к Archimatetool:
- https://www.archimatetool.com/downloads/Archi%20User%20Guide.pdf

Archimatetool использует Grafico format файлов:
📝 "GRAFICO stands for "Git Friendly Archi File Collection" and is a way to persist an ArchiMate model in a bunch of XML files (one file per ArchiMate element or view)."
https://github.com/archi-contribs/archi-grafico-plugin/wiki/GRAFICO-explained

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

Кстати, в Archimate можно делать и C4 Model, сохранив единую модель для всех её представлений:
- https://www.archimatetool.com/blog/2020/04/18/c4-model-architecture-viewpoint-and-archi-4-7/

Event Storming by PlantUML:
- https://github.com/tmorin/plantuml-libs/blob/master/dist/eventstorming/README.md

#EventStorming #DDD #Microservices #SoftwareArchitecture #ArchiMate

Этот парень знает, что пишет:
https://news.1rj.ru/str/yarosh_log/73

#Algorithms #Parsers

Еще немного на тему Operational Transform and CRDT.

В конце т.н. "Красной Книги" - "Implementing Domain-Driven Design", Vaughn Vernon рассматривает автоматическое слияние изменений агрегата (автоматический резольв конфликтов версий агрегата), что позволяет повысить конкурентность. См. главу "Appendix A Aggregates and Event Sourcing: A+ES :: Concurrency Control" и картинку "Figure A.11. Using Event conflict resolution on the Event Stream of an Aggregate".

Суть идеи в том, что хотя агрегат и был отредактирован одновременно двумя пользователями, но, используя Event Sourcing, можно слить изменения, если они не конфликтуют между собой (например, не изменяют значение одного и того же атрибута агрегата). Главное, чтобы это не нарушало инвариантов агрегата, которые на уровне слияния событий обеспечить редко когда возможно.

"Which Programming Languages Use the Least Electricity?" by David Cassel
https://thenewstack.io/which-programming-languages-use-the-least-electricity/

#SoftwareArchitecture

В продолжение темы - есть еще "Дивергентное мышление и конвергентное мышление"
https://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B2%D0%B5%D1%80%D0%B3%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D0%B5_%D0%BC%D1%8B%D1%88%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

#Career #SoftwareDesign #SoftwareArchitecture

"Developer to Architect :: Training and resources for the journey from software developer to software architect"
by Mark Richards, Software Architect and Founder
https://www.developertoarchitect.com/lessons/

#SoftwareArchitecture

📝 "Motivation

Thirty years ago Yourdon and Constantine in Structured Design identified economics as the underlying driver of software design. Software should be designed to reduce its overall cost. The cost of software is divided into the initial cost and the cost of maintenance:

cost total = cost develop + cost maintain

Once the industry gained experience with software development, it was a big surprise to many that the cost of maintenance is much higher than the cost of initial development. (Projects with little or no maintenance should use a very different set of implementation patterns from those presented in the remainder of this book.)

Maintenance is expensive because understanding existing code is timeconsuming and error-prone. Making changes is generally easy when you know what needs changing. Learning what the current code does is the expensive part. Once the changes are made, they need to be tested and deployed.

cost maintain = cost understand + cost change + cost test + cost deploy

One strategy for reducing overall cost is to invest more in initial development in hope of reducing or eliminating the need for maintenance. Such efforts have generally failed to reduce overall costs. When code needs to change in unanticipated ways, no amount of forethought can perfectly prepare the code for change. The premature attempts to make the code general enough to meet future needs often interfere with the unanticipated changes that turn out to be necessary.

Substantially increasing the up-front investment in software runs counter to two important economic principles: the time value of money and the uncertainty of the future. Since a dollar today is worth more than a dollar tomorrow, in principle an implementation strategy should generally encourage deferring costs. Also, because of uncertainty an implementation strategy should generally take immediate benefits in preference over possible long-term benefits. While this may sound like a license to hack without regard for the future, the implementation patterns are focused on ways to gain immediate benefit while setting up clean code for ease of future development.

My strategy for reducing overall costs is to ask all programmers to address the cost of understanding code during the maintenance phase by focusing on communicating, programmer-to-programmer. The immediate benefits of clear code are fewer defects, easier sharing of code, and smoother development. Once a set of implementation patterns has become habitual, I program faster and with fewer distracting thoughts. When I began writing my first set of implementation patterns (The Smalltalk Best Practice Patterns, Prentice Hall 1996) I thought I was a proficient programmer. To encourage myself to focus on patterns, I refused to type a character of code unless I had first written down the pattern I was following. It was frustrating, like I was coding with my fingers glued together. For the first week every minute of coding was preceded by an hour of writing. The second week I found I had most of the basic patterns in place and most of the time I was following existing patterns. By the third week I was coding much faster than I had before, because I had carefully looked at my own style and I wasn’t nagged by doubts.

The implementation patterns that I wrote down were only partly my own invention. Most of my style was copied from earlier generations of programmers. They were the habits that resulted in code that was easier to read, understand, and modify, and by codifying them I was able to code more quickly and fluidly than I had before. I could prepare for the future and get today’s code done faster at the same time."

For the implementation patterns in this book I looked at existing code as well as my own habits for inspiration. I read and compared code from the JDK, from Eclipse, and from my experience of development. The resulting patterns are intended to be a coherent view of how to write code people can understand. Other points of view or sets of values would result in different patterns. For example, I sketch the implementation patterns for framework development in “Evolving Frameworks”. These are based on a different set of priorities and so vary from my basic implementation style.

The implementation patterns serve human as well as economic needs. Code is by people and for people. Programmers can use the implementation patterns to help satisfy human needs, like the need to take pride in work well done or the need to be a trustworthy member of a community. I discuss the human and economic impact of the patterns as we go in the following chapters."
- "Implementation Patterns" by Kent Beck

#SoftwareDesign

В последнее время наметилась определенная поляризация парадигм программирования в индустрии.

Стремительный рост объема обрабатываемых данных, потребность в масштабировании, распределенном хранении и параллельной обработке данных, пробудили интерес к функциональному программированию.

📝 "Все состояния гонки (race condition), взаимоблокировки (deadlocks) и проблемы параллельного обновления обусловлены изменяемостью переменных. Если в программе нет изменяемых переменных, она никогда не окажется в состоянии гонки и никогда не столкнется с проблемами одновременного изменения. В отсутствие изменяемых блокировок программа не может попасть в состояние взаимоблокировки.

All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables. You cannot have a race condition or a concurrent update problem if no variable is ever updated. You cannot have deadlocks without mutable locks."
- "Clean Architecture: A Craftsman’s Guide to Software Structure and Design" by Robert C. Martin

Однако, индустрия не готова отказаться от императивных подвидов парадигм, таких как OOP.

Можно ли их сочетать, используя достоинства обоих видов парадигм, в зависимости от контекста использования? Как эффективно использовать мультипарадигменные языки, такие как F#, Scala, Elixir?

B.Meyer утверждает, что OOP и FP не противопоставляются, а дополняют друг друга, и ключем к достижению этого является принцип CQS. В следующих сообщениях приводится его пояснение.

#FunctionalProgramming #OOP #SoftwareDesign

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

- Нет, эти две парадигмы не являются конкурентами, они успешно могут дополнять друг друга. Тем не менее, тенденция к функциональному программированию является важной и интересной.

На мой взгляд, когда речь идет о высокоуровневой структуре приложения (особенно больших программ), то в мире нет ничего лучше объектного подхода. Я просто не вижу, как можно писать действительно большую программу исключительно на функциональном языке.

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

Несколько лет назад я опубликовал статью на эту тему, где сравнивал ОО и ФП подходы. В ней я постарался показать, что ОО метод включает функциональное программирование, а не наоборот.

- Да, я кажется читал эту статью, которая затем вошла в качестве одной из глав в книгу “Beautiful Architecture”.

- Вы знаете об этом? Я очень впечатлен.

- (Смеюсь...) Да, и насколько я помню, это был ваш ответ на статью Саймона Пейтона Джонса, в которой автор старался показать, что ФП подход является более предпочтительным.

- Да, совершенно верно.

ПРИМЕЧАНИЕ: Речь идет о статье Бертрана “Software Architecture: Functional vs. Object-Oriented Design in Beautiful Architecture”
http://se.ethz.ch/~meyer/publications/functional/meyer_functional_oo.pdf
, опубликованной в книге “Идеальная архитектура. Ведущие специалисты о красоте программных архитектур.”
https://www.amazon.com/Beautiful-Architecture-Leading-Thinkers-Software/dp/059651798X
. Эта статья Мейера была ответом на статью Саймона “Composing contracts: an adventure in financial engineering.”

- Давайте все же немного вернемся к вопросу OOP vs FP. Какие именно преимущества у функционального подхода на “низком уровне”?

- В Eiffel существует очень важный принцип, под названием Command-Query Separation Principle, который можно рассматривать, в некотором роде, как сближение ОО и ФП миров. Я не считаю, что наличие состояния – это однозначно плохо. Но очень важно, чтобы мы могли ясно различать операции, которые это состояние изменяют (т.е. командами), и операции, которые лишь возвращают информацию о состоянии, его не изменяя (т.е. запросами). В других языках эта разница отсутствует. Так, например, в С/С++ часто пишут функции, которые возвращают результат и изменяют состояние. Следование этому принципу позволяет безопасно использовать выражения с запросами зная, что они не изменяют состояние. В некоторых случаях можно пойти еще дальше и работать в чисто функциональном мире с полным отсутствием побочных эффектов."

- Bertrand Meyer в интервью Сергея Теплякова “Интервью с Бертраном Мейером“
https://sergeyteplyakov.blogspot.com/2014/05/interview-with-bertrand-meyer.html

#FunctionalProgramming #OOP #SoftwareDesign

📝 "For both theoretical and practical reasons detailed elsewhere [10], the command-query separation principle is a methodological rule, not a language feature, but all serious software developed in Eiffel observes it scrupulously, to great referential transparency advantage. Although other schools of object-oriented programming regrettable do not apply it (continuing instead the C style of calling functions rather than procedures to achieve changes), but in my view it is a key element of the object-oriented approach. It seems like a viable way to obtain the referential transparency goal of functional programming — since expressions, which only involve queries, will not change the state, and hence can be understood as in traditional mathematics or a functional language — while acknowledging, through the notion of command, the fundamental role of the concept of state in modeling systems and computations."

- “Software architecture: object-oriented vs functional” by Bertrand Meyer http://se.ethz.ch/~meyer/publications/functional/meyer_functional_oo.pdf