Заслуживающая внимания новая статья от Nick Tune - "Nurturing Design in Your Software Engineering Culture"
https://medium.com/nick-tune-tech-strategy-blog/nurturing-design-in-your-software-engineering-culture-3f960d321af

#DDD #SoftwareDesign #SoftwareArchitecture

Awesome Domain Storytelling
- https://github.com/hofstef/awesome-domain-storytelling

#DDD #SoftwareDesign #SoftwareArchitecture #EventStorming #DomainStorytelling

Запись сегодняшнего ТелеграмХауса, посвященного вопросам DDD, который состоялся сегодня в большом архитектурном чате Максима Смирнова: https://news.1rj.ru/str/it_arch/1030

#DDD #SoftwareArchitecture

Alan Kay сравнивает OOP с биологическими клетками и интернетом, Niklaus Wirt - с операционной системой, а Bertrand Meyer - с рыночной экономикой:

📝 "Политика невмешательства в обществе модулей

Только что намеченный метод описания структур данных выглядит довольно эгоистичным подходом в мире структур данных. Нас не столько интересует то, что они собой представляют внутренне, как то, что они могут друг другу предложить. В этом мы похожи на экономиста - пылкого приверженца теорий приоритета производства и невидимой руки, воспитанного в духе школы "пусть-все-решит-свободный-рынок". Мир объектов (а, следовательно, и архитектуры ПО) будет миром взаимодействующих объектов, общающихся на основе точно определенных протоколов.

Аналогия с экономикой будет сопровождать наше изложение и дальше, агенты - программные модули - называются поставщиками и клиентами, протоколы будут называться контрактами, и большая часть ОО-разработки, на самом деле, может рассматриваться как "Проектирование по Контракту" - это заголовок одной из следующих лекций.

Не следует чересчур увлекаться этой аналогией (как и всякой другой): эта работа не учебник по экономике и она не содержит даже намеков на точку зрения автора в этой области. Сейчас нам достаточно отметить поразительные аналогии подхода абстрактных типов данных с некоторыми теориями о взаимодействии агентов-людей.

A laissez-faire policy for the society of modules

The method just outlined for describing data structures shows a rather selfish approach to the world of data structures: like an economist of the most passionate supply-side, invisible-hand, let-the-free-market-decide school, we are interested in individual agents not so much for what they are internally as for what they have to offer to each other. The world of objects (and hence of software architecture) will be a world of interacting agents, communicating on the basis of precisely defined protocols.

The economic analogy will indeed accompany us throughout this presentation; the agents — the software modules — are called suppliers and clients; the protocols will be called contracts, and much of object-oriented design is indeed Design by Contract, the noscript of a later chapter.

As always with analogies, we should not get too carried away: this work is not a textbook on economics, and contains no hint of its author’s views in that field. It will suffice for the moment to note the remarkable analogies of the abstract data type approach to some theories of how human agents should work together. Later in this chapter we will again explore what abstract data types can tell us beyond their original area of application."
- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer

#OOP #SoftwareDesign

📝 "Если бы у Java был настоящий сборщик мусора, большинство программ удаляли бы себя во время исполнения." — Роберт Сьюэл 🙂

#Юмор

Многие знают про стандарт ISO/IEC/IEEE 42010:2011, но не все слышали про 42020 и 42030.

#SoftwareArchitecture

Вот как понимает OOP Robert C. Martin:

📝 "Объектно-ориентированное
программирование

Второй парадигмой, получившей широкое распространение, стала парадигма, в действительности появившаяся двумя годами ранее, в 1966-м, и предложенная Оле-Йоханом Далем и Кристеном Нюгором. Эти два программиста заметили, что в языке ALGOL есть возможность переместить кадр стека вызова функции в динамическую память (кучу), благодаря чему локальные переменные, объявленные внутри функции, могут сохраняться после выхода из нее. В результате функция превращалась в конструктор класса, локальные переменные — в переменные экземпляра, а вложенные функции — в методы. Это привело к открытию полиморфизма через строгое использование указателей на функции.

Подводя итог, можно сказать, что:

Объектно-ориентированное программирование накладывает ограничение на косвенную передачу управления.

<...>

Что такое ОО? Существует много взглядов и ответов на этот вопрос. Однако для программного архитектора ответ очевиден: ОО дает, посредством поддержки полиморфизма, абсолютный контроль над всеми зависимостями в исходном коде. Это позволяет архитектору создать архитектуру со сменными модулями (плагинами), в которой модули верхнего уровня не зависят от модулей нижнего уровня. Низкоуровневые детали не выходят за рамки модулей плагинов, которые можно развертывать и разрабатывать независимо от модулей верхнего уровня.

OBJECT-ORIENTED PROGRAMMING

The second paradigm to be adopted was actually discovered two years earlier, in 1966, by Ole Johan Dahl and Kristen Nygaard. These two programmers noticed that the function call stack frame in the ALGOL language could be moved to a heap, thereby allowing local variables declared by a function to exist long after the function returned. The function became a constructor for a class, the local variables became instance variables, and the nested functions became methods. This led inevitably to the discovery of polymorphism through the disciplined use of function pointers.

We can summarize the object-oriented programming paradigm as follows:

Object-oriented programming imposes discipline on indirect transfer of control.

<...>

What is OO? There are many opinions and many answers to this question. To the software architect, however, the answer is clear: OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies."
- "Clean Architecture: A Craftsman’s Guide to Software Structure and Design" by Robert C. Martin

Его статья "Three Paradigms"
https://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html

#OOP #SoftwareDesign

"Шпаргалка по функциональному программированию" - Блог компании Яндекс

https://habr.com/ru/company/yandex/blog/547786/

#FunctionalProgramming

"От внедрения зависимостей к отказу от зависимостей" - Mark Seemann, перевод Максима Аршинова
https://habr.com/ru/company/jugru/blog/545482/

#FunctionalProgramming #SoftwareDesign

"Reporting models and Event Sourcing" by Alexey Zimarev ( @zimareff )
https://zimarev.com/blog/event-sourcing/changes-in-event-sourced-systems/

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

"Say hello to Eventuous" by Alexey Zimarev ( @zimareff )
- https://zimarev.com/blog/event-sourcing/say-hello-to-eventuous/

A minimalistic Event Sourcing library for .NET
- https://github.com/Eventuous/eventuous

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

"The dispassionate developer" by Mark Seemann
https://blog.ploeh.dk/2021/03/22/the-dispassionate-developer/

Только сегодня его вспоминали) Неплохая, кстати, статья.

#Career

"A recipe for gradually migrating from CRUD to Event Sourcing" by Dennis Doomen
https://www.eventstore.com/blog/a-recipe-for-gradually-migrating-from-crud-to-event-sourcing

#DDD #EventSourcing #SoftwareDesign #SoftwareArchitecture

Коллеги поделились мультиком о Скраме 😂))
https://coub.com/view/253kyu

#Agile #Юмор

"Trannoscript of Greg Young's Talk at Code on the Beach 2014: CQRS and Event Sourcing" by Greg Young
https://www.eventstore.com/blog/trannoscript-of-greg-youngs-talk-at-code-on-the-beach-2014-cqrs-and-event-sourcing

#DDD #EventSourcing #CQRS #SoftwareDesign #SoftwareArchitecture

Современное определение OOP:

📝 "Объектно-ориентированное программирование — это метод программирования, основанный на представлении программы в виде
совокупности взаимодействующих объектов, каждый из которых является экземпляром определенного класса, а классы являются членами определенной иерархии наследования.

Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."

📝 "Объектно-ориентированное программирование (object-oriented programming). Методология программирования, в которой программы представляют собой совокупности взаимодействующих объектов, каждый из которых является экземпляром определенного класса, входящего в иерархию классов, связанных отношением наследования. В таких программах классы обычно считаются статичными сущностями, а объекты имеют более динамичную природу, поддерживаемую механизмами динамического связывания и полиморфизма.

Object-oriented programming.
A method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. In such programs, classes are generally viewed as static, whereas objects typically have a much more dynamic nature, which is encouraged by the existence of dynamic binding and polymorphism."

- "Object-Oriented Analysis and Design with Applications" 3rd edition by Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young Ph.D., Jim Conallen, Kelli A. Houston

Кстати, есть мнение, что тут не обошлось без коммерции:

📝 "OO is merely a clever and successful MarketingScheme which has made Grady Booch a wealthy man. -- Daniel Brockman"
https://wiki.c2.com/?NobodyAgreesOnWhatOoIs

#OOP #SoftwareDesign

Ранее в этом треде приводилось выссказывание Niklaus Wirt об обстоятельствах, при которых внедрялось OOP. Он писал о модных поветриях и причинах коммерческого порядка.

О коммерческих причинах пишет и основатель языка программирования Erlang - Joe Armstrong:

📝 "At this point I am reminded of the keynote speech of the then boss of IBM in France who addressed the audience at the 7th IEEE Logic programming conference in Paris. IBM Prolog had added a lot of OO extensions. When asked why he replied:

Our customers wanted OO Prolog so we made OO Prolog

I remember thinking “How simple, no qualms of conscience, no soul-searching, no asking ‘Is this the right thing to do’ …”"
- "Why OO Sucks" by Joe Armstrong
https://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm

#OOP #FunctionalProgramming #SoftwareDesign

Это наверное, лучшее объяснение, которое я встречал, о том, чем отличается FP от OOP, и что у них общего:

📝 "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts."
- Michael Feathers
https://twitter.com/mfeathers/status/29581296216

Это высказывание так же поясняет, почему Functional Programming не равно Anemic Domain Model. Все дело в том, что в Functional Programming обеспечивается ссылочная прозрачность, т.е. накладывается ограничение на изменяемость данных. А между тем, основной недостаток утраты инкапсуляции в Anaemic Domain Model заключается именно в утрате контроля за изменением состояния и обеспечением инвариантов.

#OOP #FunctionalProgramming #SoftwareDesign

В развитие темы о моделировании DDD-агрегатов. На мой взгляд множество внятных предложений по расширению реляционной модели данных дал сам Edgar F. Codd в своей статье 1979 года Extending the Database Relational Model to Capture More Meaning (см. перевод здесь: http://citforum.ru/database/classics/codd_2/) Работа сложная (как впрочем и непосредственно реляционная модель, описанная им десятью годами раньше), для любителей посидеть, подумать, поразбираться с моделированием данных, но очень ёмкая. Жаль, что десятая глава декартова агрегация(Cartesian aggregation) в ней слишком лаконична