emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Оказывается, в Archi вполне нормально можно вести бэклог разработки (используя Canvas).

Кстати, в тему обсуждения, доклад Сергея Баранова о восстановлении знаний об архитектуре системы: Доклад - https://www.youtube.com/live/4SEe2bx7090 Презентация - https://t.me/microservices_arch/531

На данном этапе у нас должны получиться следующие архитектурные артефакты: 1. Диаграмма трассировки требований. Я использую Motivation View Points. 2. EventStorming диаграммы. Я использую "C.1.10. Business Process Cooperation Viewpoint". Подробнее здесь. Шпаргалки по EventStorming здесь. 3. Context Map. Я делаю как в "Model used by Jean-Baptiste Sarrodie for presentation "Enterprise Architecture Modelling with ArchiMate in an Agile at Scale Programme" (демонстрационная модель от автора OpenSource среды проектирования Archi). Но есть и другие инструменты, перечисленные здесь.

💬 Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении. Коггинс коворит: «Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.» Рисковать реальными начальными деньгами ради предполагаемых, но неопределенных прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий. The benefits, which I think are real and not merely putative, occur all along the development cycle; but the big benefits pay off dur-ing successor building, extension, and maintenance activities. Coggins says, "Object-oriented techniques will not make the first project development any faster, or the next one. The fifth one in that family will go blazingly fast." Betting real up-front money for the sake of projected but iffy benefits later is what investors do every day. In many program-ming organizations, however, it requires real managerial cour-age, a commodity much scarcer than technical competence or administrative proficiency. I believe the extreme degree of cost front-loading and benefit back-loading is the largest single factor slowing the adoption of O-O techniques. —"The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr.

Чем интересна эта фраза? Она утвердает, что источником кризиса в архитектуре, например, в результате применения Anemic Domain Model, является недостаток морально-деловых качеств управленцев (недостаток смелости смотреть в лицо неопределенности).

Был вопрос о том, как выглядят доменные модели в функциональной парадигме: - https://github.com/swlaschin/DomainModelingMadeFunctional - https://github.com/swlaschin/Railway-Oriented-Programming-Example - https://github.com/swlaschin/RailwayOrientedProgramming Ряд других примеров для курсов и воркшопов: - https://github.com/swlaschin?tab=repositories На Idris: - https://github.com/andorp/order-taking

В какой-то одной парадигме реализовывать систему может оказаться трудно, поэтому и был создан принцип CQS, позволяющий использовать преимущества обоих парадигм, как OOP, так и FP, - эта тема уже затрагивалась: https://t.me/emacsway_log/265

Ну и формальное определение абстракции:

💬 Abstraction is one of the fundamental ways that we as humans cope with complexity. Dahl, Dijkstra, and Hoare suggest that “abstraction arises from a recognition of similarities between certain objects, situations, or processes in the real world, and the decision to concentrate upon these similarities and to ignore for the time being the differences” [42]. Shaw defines an abstraction as “a simplified description, or specification, of a system that emphasizes some of the system’s details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment, immaterial or diversionary” [43]. Berzins, Gray, and Naumann recommend that “a concept qualifies as an abstraction only if it can be described, understood, and analyzed independently of the mechanism that will eventually be used to realize it” [44]. Combining these different viewpoints, we define an abstraction as follows: An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer. An abstraction focuses on the outside view of an object and so serves to separate an object’s essential behavior from its implementation. Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46]. We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction. -- "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

Обратимся к первоисточнику термина "сокрытие информации" - к статье "On the Criteria to Be Used in Decomposing Systems Into Modules." by David Parnas:

💬 Information-hiding objects can be created in any language; my first experiments used primitive versions of FORTRAN.

Это противоречит англоязычной версии статьи Википедии о том, что сокрытие информации является свойством ЯП.

💬 When it is applied properly it is usually successful. Abstractions such as Unix pipes, postscript or X-win-dows achieve the goal of allowing several implementations of the same interface. However, although the principle was published 30 years ago, today’s software is full of places where information is not hidden, interfaces are complex, and changes are unreasonably difficult.

💬 While the basic idea is to hide information that is likely to change, one can often profit by hiding other information as well because it allows the re-use of algorithms or the use of more efficient algorithms.

Здесь мы видим цель сокрытия информации - упростить изменение программы путем управления Coupling, т.е. относится к области конструкции с точки зрения дихотомии функции и конструкции. Инкапсуляция же отделяет конструкцию от функции. Она защищает интерфейс, который экспонирует поведение, т.е. функцию. Мы разбиваем систему на компоненты, чтобы управлять сложностью, и на модули - чтобы управлять измением системы.

💬 The terms "module" and "component" are often used interchangeably, which causes confusion. As I mentioned earlier, any system is composed of components. Therefore, a module is a component. However, not every component is a module. To design a flexible system it’s not enough to decompose a system into an arbitrary set of components. Instead, a modular design should enable you to alter the system by combining, reconfiguring, or replacing its components — its modules. -- "Balancing Coupling in Software Design: Universal design principles for architecting modular software systems" by Vlad Khononov

В качестве примера модуля Vlad приводит кубик конструктора Lego. О том, что всякий модуль есть компонент, можно подискутировать по поводу примера с ножницами, но выделим главное: модуль - это о конструкции, компонет - о функции. Таким образом, что отличие между инкапсуляцией и сокрытием информации такое же, как между DIP и DI - второе является способом достижения первого.

💬 Encapsulation is most often achieved through information hiding (not just data hiding). -- "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

💬 InformationHiding should inform the way you encapsulate things -- https://wiki.c2.com/?EncapsulationIsNotInformationHiding

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

💬 Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. -- "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

💬 "Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior. Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential charac-teristics; typically, the structure of an object is hidden, as well as the implementa-tion of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51]. Encapsulation hides the details of the implementation of an object. Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant. To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data but depend only on a schema that denotes the data’s logical view [52]. In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction. “For abstraction to work, implementations must be encapsulated” [53]. In practice, this means that each class must have two parts: an interface and an imple-mentation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions. To summarize, we define encapsulation as follows: Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Britton and Parnas call these encapsulated elements the “secrets” of an abstrac-tion [54]. <...> Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity. Thus, encapsulation cannot stop a developer from doing stupid things; as Stroustrup points out, “Hiding is for the prevention of accidents, not the prevention of fraud” [56]. Of course, no programming language prevents a human from literally seeing the implementation of a class, although an operating system might deny access to a particular file that contains the implementation of a class. -- "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

Смотрите так же статьи в wiki by Ward Cunningham: - https://wiki.c2.com/?EncapsulationDefinition - https://wiki.c2.com/?EncapsulationIsNotInformationHiding - https://wiki.c2.com/?InformationHiding Обратите внимание, что текст по второй ссылке прямо противоречит статье в Википедии (причем, русскоязычный вариант статьи противоречит англоязычному - в одном варианте свойством языка является инкасуляция, а в другом - сокрытие), поэтому я стараюсь избегать ссылок на Википедию.

Целью данного цикла постов является антикризиная архитектура, поэтому, сейчас мы не будем погружаться в подробности истории зарождения OOP, тем более, что на эту тему уже был цикл постов. В контексте нашей цели интересно только то, каким образом OOP может способствовать управлению существенной сложностью. Обратите внимание, что цитаты из "The Mythical Man-Month Essays on Software Engineering Anniversary Edition" by Frederick P. Brooks, Jr. взяты из главы ""No Silver Bullet" Refired", которая является продолжением известной его статьи "No Silver Bullet - Essence and Accident in Software Engineering" by Frederick P. Brooks, Jr. Иными словами, эти цитаты имеют непосредственное отношение к управлению существенной сложностью. Простым языком про абстракцию и инкапсуляцию писал Сергей Тепляков (который лично знаком с Bertrand Meyer) в статье "О дружбе значимых типов с ООП". Далее я приведу формальное определение от Grady Booch, посколько именно его определения значительным образом повлияли на современное OOP.