emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности (когда-то затрагивал эту тему здесь). Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место…
Разрешение неопределенности опытным путем не может обладать наивысшим уровнем эффективности потому, что информация о правильности решения (т.е. о соответствии решения текущим условиям) возникает в результате эксперимента. Т.е. часть ресурсов изначально закладывается на получение информации, т.е. на опровергание неудачных гипотез. Иными словами, чтобы сократить количество вариантов, сперва нужно потратить ресурсы на увеличение количества вариантов, иначе просто нечего будет сокращать. Конвергентная фаза принятия решения невозможна без дивергентной фазы.
Именно поэтому, чем дешевле заблаговременные способы разрешения неопределенности, тем дешевле можно вести разработку программного продукта. Именно этим обусловлен феномен успеха Event Storming - он снижает стоимость заблаговременного способа разрешения неопределенности, что позволяет минимизировать долю эмпирического способа обработки неопределенности. Как говорится,
💬 "пять дней кодинга могут сэкономить один день планирования".
По этой же причине, рыночная экономика, в основе которой лежит adaptation (в отличии от плановой экономики), немыслима без кризисов и войн - чтобы истреблять слабо приспособленные формы хозяйствования. Конкуренция генерирует новые формы хозяйствования, а кризисы их сокращают. Т.е. механизм экономической эволюции по своей сути мало чем отличается от механизма биологической эволюции.
Мы можем иметь разное отношение к хищническим способам его функционирования, но он на протяжении веков обеспечивает свою ключевую функцию - сохранение жизни на планете в условиях переменчивости окружающей среды. Да, динозавры, как форма жизни, прекратили свое существование, но сама жизнь на планете продолжается.
И тут мы подошли к ключевой цели Evolutionary Architecture.
Как я уже говорил, архитектурное решение - это сокращение количества возможных вариантов. Robert Martin говорил, что архитектура - это о том, как не надо делать.
Что такое вариант архитектурного решения? Это конфигурация комбинации элементов системы. Что такое система? Это математическая свертка архитектурных решений. Именно поэтому, ADR документирует системный инкремент (т.е. изменение системы), а не саму систему.
💬 A system is never the sum of its parts. It is the product of the interactions of its parts.
-- Dr. Russel Ackoff
Мы подошли к тому, чтобы понять идею автора Evolutionary Architecture. Еще раз выделю главное:
задача эволюции заключается в том, чтобы обеспечить выживаемость путем способствования репродукции наиболее приспособленной (т.е. соответствующей) текущим условиям комбинации ген (или элементов системы, или организационных форм хозяйствования и т.д.).
Продолжение...
Именно поэтому, чем дешевле заблаговременные способы разрешения неопределенности, тем дешевле можно вести разработку программного продукта. Именно этим обусловлен феномен успеха Event Storming - он снижает стоимость заблаговременного способа разрешения неопределенности, что позволяет минимизировать долю эмпирического способа обработки неопределенности. Как говорится,
💬 "пять дней кодинга могут сэкономить один день планирования".
По этой же причине, рыночная экономика, в основе которой лежит adaptation (в отличии от плановой экономики), немыслима без кризисов и войн - чтобы истреблять слабо приспособленные формы хозяйствования. Конкуренция генерирует новые формы хозяйствования, а кризисы их сокращают. Т.е. механизм экономической эволюции по своей сути мало чем отличается от механизма биологической эволюции.
Мы можем иметь разное отношение к хищническим способам его функционирования, но он на протяжении веков обеспечивает свою ключевую функцию - сохранение жизни на планете в условиях переменчивости окружающей среды. Да, динозавры, как форма жизни, прекратили свое существование, но сама жизнь на планете продолжается.
И тут мы подошли к ключевой цели Evolutionary Architecture.
Как я уже говорил, архитектурное решение - это сокращение количества возможных вариантов. Robert Martin говорил, что архитектура - это о том, как не надо делать.
Что такое вариант архитектурного решения? Это конфигурация комбинации элементов системы. Что такое система? Это математическая свертка архитектурных решений. Именно поэтому, ADR документирует системный инкремент (т.е. изменение системы), а не саму систему.
💬 A system is never the sum of its parts. It is the product of the interactions of its parts.
-- Dr. Russel Ackoff
Мы подошли к тому, чтобы понять идею автора Evolutionary Architecture. Еще раз выделю главное:
задача эволюции заключается в том, чтобы обеспечить выживаемость путем способствования репродукции наиболее приспособленной (т.е. соответствующей) текущим условиям комбинации ген (или элементов системы, или организационных форм хозяйствования и т.д.).
Продолжение...
Хабр
Темные века разработки программного обеспечения
Пару лет назад я работал в SaaS-компании, которая страдала от всех возможных проблем, связанных с разработкой программного обеспечения . Код был настолько сложным, что внесение простых изменений...
👍4😁1😐1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Разрешение неопределенности опытным путем не может обладать наивысшим уровнем эффективности потому, что информация о правильности решения (т.е. о соответствии решения текущим условиям) возникает в результате эксперимента. Т.е. часть ресурсов изначально закладывается…
Теперь обратимся к автору Evolutionary Architecture:
💬 Going back to our biological metaphor, evolutionary is about the process of having a system that is fit for purpose and can survive the everchanging environment in which it operates. Systems may have individual adaptations, but as architects, we should care about the overall evolvable system.
Ключевые моменты (еще раз):
1. Изменчивость среды функционирования.
2. Выживаемость.
3. Роль архитектора.
Вот с ролью архитектора не очень пока понятно. Идем дальше:
💬 The authors borrow a concept from evolutionary computing called “fitness functions,” used in genetic
algorithm design to define success. Evolutionary computing includes a
number of mechanisms that allow a solution to gradually emerge via small changes in each generation of the software. At each generation of the solution, the engineer assesses the current state: Is it closer to or further away from the ultimate goal? For example, when using a genetic algorithm to optimize wing design, the fitness function assess wind resistance, weight, air flow, and other characteristics desirable to good wing design. Architects define a fitness function to explain what better is and to help measure when the goal is met. In software, fitness functions check that developers preserve important architectural characteristics.
We use this concept to define architectural fitness functions:
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).
Ключевые моменты:
1. В основу идеи положен генетический механизм адаптации форм жизни под изменяемость окружающей среды.
2. Поколение системы (текущая версия системы) основана как на наследовании структурной комбинации предыдущего поколения, так и на её изменении.
3. Инженер оценивает текущий уровень приспособленности системы. Сам термин fitness означает приспособленность, соответствие.
Важный момент - не просто удовлетворяет требованиям, а именно "Is it closer to or further away from the ultimate goal", т.е. является ли он лучше или хуже. Происходит сравнение двух вариантов. Именно этот момент многие не понимают, и это ставит крест на идее эволюции архитектуры.
Многие считают, что назначение fitness functions сводится к тому, чтобы просто протестировать новую версию системы, чтоб она просто прошла заданный набор тестовых кейсов. Это не верно. Их назначение - оценить, насколько лучше или хуже стала новая версия системы. В системе изменилась конфигурация комбинации её элементов (подобно комбинации ген поколения). Зачача архитектора - хищническая, и заключается она в том, чтоб сократить количество вариантов "генетических комбинаций". Вспоминаем, что архитектурное решение есть результат сокращения количества возможных вариантов. Архитектор решает, какой вариант структурной комбинации системы должен умереть и не должен больше воспроизводиться (репродуцироваться) в новых поколениях системы. Происходит то, что называется в биологии "селекция". В результате истребления наименее приспособленного варианта происходит то, что в приведенной цитате называется "to optimize".
После этого решение можно зафиксировать, изменив параметры fitness function на более строгие, соответствующие достигнутым текущей комбинации системы. Таким образом происходит эволюция системы, т.е. повышение уровня соответствия системы текущим условиям. Именно об этом говорит автор:
💬 The systemwide fitness function is crucial for an architecture to be evolutionary, as we need some basis to allow architects to compare and evaluate architectural characteristics against one another. Unlike the more directed fitness functions, architects will likely never try to “evaluate” this systemwide fitness function. Rather, it provides guidelines for prioritizing decisions about the architecture in the future.
Продолжение...
💬 Going back to our biological metaphor, evolutionary is about the process of having a system that is fit for purpose and can survive the everchanging environment in which it operates. Systems may have individual adaptations, but as architects, we should care about the overall evolvable system.
Ключевые моменты (еще раз):
1. Изменчивость среды функционирования.
2. Выживаемость.
3. Роль архитектора.
Вот с ролью архитектора не очень пока понятно. Идем дальше:
💬 The authors borrow a concept from evolutionary computing called “fitness functions,” used in genetic
algorithm design to define success. Evolutionary computing includes a
number of mechanisms that allow a solution to gradually emerge via small changes in each generation of the software. At each generation of the solution, the engineer assesses the current state: Is it closer to or further away from the ultimate goal? For example, when using a genetic algorithm to optimize wing design, the fitness function assess wind resistance, weight, air flow, and other characteristics desirable to good wing design. Architects define a fitness function to explain what better is and to help measure when the goal is met. In software, fitness functions check that developers preserve important architectural characteristics.
We use this concept to define architectural fitness functions:
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).
Ключевые моменты:
1. В основу идеи положен генетический механизм адаптации форм жизни под изменяемость окружающей среды.
2. Поколение системы (текущая версия системы) основана как на наследовании структурной комбинации предыдущего поколения, так и на её изменении.
3. Инженер оценивает текущий уровень приспособленности системы. Сам термин fitness означает приспособленность, соответствие.
Важный момент - не просто удовлетворяет требованиям, а именно "Is it closer to or further away from the ultimate goal", т.е. является ли он лучше или хуже. Происходит сравнение двух вариантов. Именно этот момент многие не понимают, и это ставит крест на идее эволюции архитектуры.
Многие считают, что назначение fitness functions сводится к тому, чтобы просто протестировать новую версию системы, чтоб она просто прошла заданный набор тестовых кейсов. Это не верно. Их назначение - оценить, насколько лучше или хуже стала новая версия системы. В системе изменилась конфигурация комбинации её элементов (подобно комбинации ген поколения). Зачача архитектора - хищническая, и заключается она в том, чтоб сократить количество вариантов "генетических комбинаций". Вспоминаем, что архитектурное решение есть результат сокращения количества возможных вариантов. Архитектор решает, какой вариант структурной комбинации системы должен умереть и не должен больше воспроизводиться (репродуцироваться) в новых поколениях системы. Происходит то, что называется в биологии "селекция". В результате истребления наименее приспособленного варианта происходит то, что в приведенной цитате называется "to optimize".
После этого решение можно зафиксировать, изменив параметры fitness function на более строгие, соответствующие достигнутым текущей комбинации системы. Таким образом происходит эволюция системы, т.е. повышение уровня соответствия системы текущим условиям. Именно об этом говорит автор:
💬 The systemwide fitness function is crucial for an architecture to be evolutionary, as we need some basis to allow architects to compare and evaluate architectural characteristics against one another. Unlike the more directed fitness functions, architects will likely never try to “evaluate” this systemwide fitness function. Rather, it provides guidelines for prioritizing decisions about the architecture in the future.
Продолжение...
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности (когда-то затрагивал эту тему здесь).
Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место…
Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место…
👍6❤1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Теперь обратимся к автору Evolutionary Architecture: 💬 Going back to our biological metaphor, evolutionary is about the process of having a system that is fit for purpose and can survive the everchanging environment in which it operates. Systems may have…
Вся эта сложность нужна потому, что
💬 We can also think about the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture. Using a systemwide fitness function aids our understanding of necessary tradeoffs when individual elements of the fitness function conflict with each other.
As is common with multifunction optimization problems, we might find it impossible to optimize all values simultaneously, forcing us to make choices. For example, in the case of architectural fitness functions, issues like performance might conflict with security due to the cost of encryption. This is a classic example of the bane of architects everywhere — the tradeoff.
И снова здесь говорится о сути эволюционной архитектуры - не просто удовлетворить текущий набор тестовых кейсов, а оптимизировать значения свойств системы.
Возвращаемся к статье https://www.thoughtworks.com/en-gb/insights/articles/fitness-function-driven-development
Затрудняюсь ответить, что больше от этой статьи, пользы или вреда. Статья уволит в сторону от ключевой идеи fitness function. Авторы воспринимают TDD как способ тестирования, в то время как TDD является способом проектирования. И уж TDD точно никогда не предназначался для повышения "test coverage".
А между тем, хотя авторы и не раскрыли темы, но аналогия с TDD сама по себе очень удачна, правда, по другой причине - один из мощнейших механизмов TDD является триангуляция, т.е. когда из двух частных вариантов реализации выводится один обобщенный вариант. Иными словами, изменяемость внешних условий (тестовых кейсов) вызывает изменение структурной комбинации предыдущей версии реализации таким образом, чтобы унаследовались свойства, удовлетворяющие предыдущим условиям, но изменились те, которые не удовлетворяли новым условиям. Происходит эволюция решения, с присутствием признаков наследования и адаптации. Выживает решение, которое более приспособлено.
Несмотря на то, что статья правильно цитирует назначение fitness function:
💬 Fitness functions describe how close an architecture is to achieving an architectural aim.
Далее она входит в противоречие с этим утверждением. Например, здесь говорится не о селекции архитектурных решений, а о достаточности прохождения теста, что в корне убивает всю изначальную задумку:
💬 As a result, every new service or piece of software is developed in a way that passes the fitness functions and supports the architectural qualities we value.
А здесь и того хуже - измеряется технический долг, что свидетельствует о деградации решения (а значит, эволюция не работает), и непонятно зачем за уши притянуто качество кода:
💬 First, fitness function-driven development objectively measures technical debt and drives code quality.
Снова речь идет не о селекции архитектурных решений, а о достаточности прохождения тестовых кейсов:
💬 teams are quickly notified of the changes, able to react quickly, and have objective tests to validate conformance.
💬 With architecture goals expressed as code, conformance tests can be incorporated in build pipelines to monitor alignment with the architectural “-ilities” that are most critical.
Сравним это с утверждением автора оригинала:
💬 to allow architects to compare and evaluate architectural characteristics against one another.
Чувствуете разницу между "пройти набор тестовых кейсов" и "сравнить и эволюционировать", т.е. "лучше соответствовать" окружающим условиям? А для этого архитектор должен осуществить роль хищника, сокращающего количество возможных вариантов решения на основании степени их соответствия условиям. Решение, не соответствующее условиям, истреблять не нужно - им занимаются уже падальщики. Оно и так уже не выжило. Суть эволюции в том, чтобы обеспечить выживаемость.
Статья является очередным примером, демонстрирующим почему важно работать с первоисточниками.
Продолжение...
💬 We can also think about the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture. Using a systemwide fitness function aids our understanding of necessary tradeoffs when individual elements of the fitness function conflict with each other.
As is common with multifunction optimization problems, we might find it impossible to optimize all values simultaneously, forcing us to make choices. For example, in the case of architectural fitness functions, issues like performance might conflict with security due to the cost of encryption. This is a classic example of the bane of architects everywhere — the tradeoff.
И снова здесь говорится о сути эволюционной архитектуры - не просто удовлетворить текущий набор тестовых кейсов, а оптимизировать значения свойств системы.
Возвращаемся к статье https://www.thoughtworks.com/en-gb/insights/articles/fitness-function-driven-development
Затрудняюсь ответить, что больше от этой статьи, пользы или вреда. Статья уволит в сторону от ключевой идеи fitness function. Авторы воспринимают TDD как способ тестирования, в то время как TDD является способом проектирования. И уж TDD точно никогда не предназначался для повышения "test coverage".
А между тем, хотя авторы и не раскрыли темы, но аналогия с TDD сама по себе очень удачна, правда, по другой причине - один из мощнейших механизмов TDD является триангуляция, т.е. когда из двух частных вариантов реализации выводится один обобщенный вариант. Иными словами, изменяемость внешних условий (тестовых кейсов) вызывает изменение структурной комбинации предыдущей версии реализации таким образом, чтобы унаследовались свойства, удовлетворяющие предыдущим условиям, но изменились те, которые не удовлетворяли новым условиям. Происходит эволюция решения, с присутствием признаков наследования и адаптации. Выживает решение, которое более приспособлено.
Несмотря на то, что статья правильно цитирует назначение fitness function:
💬 Fitness functions describe how close an architecture is to achieving an architectural aim.
Далее она входит в противоречие с этим утверждением. Например, здесь говорится не о селекции архитектурных решений, а о достаточности прохождения теста, что в корне убивает всю изначальную задумку:
💬 As a result, every new service or piece of software is developed in a way that passes the fitness functions and supports the architectural qualities we value.
А здесь и того хуже - измеряется технический долг, что свидетельствует о деградации решения (а значит, эволюция не работает), и непонятно зачем за уши притянуто качество кода:
💬 First, fitness function-driven development objectively measures technical debt and drives code quality.
Снова речь идет не о селекции архитектурных решений, а о достаточности прохождения тестовых кейсов:
💬 teams are quickly notified of the changes, able to react quickly, and have objective tests to validate conformance.
💬 With architecture goals expressed as code, conformance tests can be incorporated in build pipelines to monitor alignment with the architectural “-ilities” that are most critical.
Сравним это с утверждением автора оригинала:
💬 to allow architects to compare and evaluate architectural characteristics against one another.
Чувствуете разницу между "пройти набор тестовых кейсов" и "сравнить и эволюционировать", т.е. "лучше соответствовать" окружающим условиям? А для этого архитектор должен осуществить роль хищника, сокращающего количество возможных вариантов решения на основании степени их соответствия условиям. Решение, не соответствующее условиям, истреблять не нужно - им занимаются уже падальщики. Оно и так уже не выжило. Суть эволюции в том, чтобы обеспечить выживаемость.
Статья является очередным примером, демонстрирующим почему важно работать с первоисточниками.
Продолжение...
Thoughtworks
Fitness function-driven development
Fitness function-driven development ensures your code has structured, sensible logging during the development process to provide the operability and debuggability required for a production application
🔥3👍2
Коллеги, если проголосуете - буду рад, но сторизы не обещаю 🙂)
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Проголосуйте за канал, чтобы он получил больше возможностей.
🔥2😁2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Вся эта сложность нужна потому, что 💬 We can also think about the systemwide fitness function as a collection of fitness functions with each function corresponding to one or more dimensions of the architecture. Using a systemwide fitness function aids our…
Еще один интересный тезис из книги, где evolutionary architecture сравнивается в селекцией породистых собак:
💬 While software architects are interested in exploring evolutionary architectures, we aren’t attempting to model biological evolution. Theoretically, we could build an architecture that randomly changed one of its bits (mutation) and redeployed itself. After a few million years, we would likely have a very interesting architecture. However, we don’t have millions of years to wait.
We want our architecture to evolve in a guided way, so we place constraints on different aspects of the architecture to reign in undesirable evolutionary directions. A good example is dog breeding: By selecting the characteristics we want, we can create a vast number of different shaped canines in a relatively short amount of time.
Что интересно в этой фразе? А интересно здесь то, что в кинологии:
💬 По мере возникновения исторических изменений в породе в стандарт могут вносится корректировки.
💬 Стандарт периодически пересматривают и изменяют, что обеспечивает прогресс породы
-- Википедия.
Прошу простить за адресацию к Википедии - всё-таки я не кинолог и не зоотехник 🙂) Последняя цитата взята из http://www.kgau.ru/distance/zif_03/razvedenie-110401/07_01.html - вроде заслуживает доверия.
Ключевой момент - изменения в стандарт вносятся не только по мере выявления желаемых свойств породы, но и по мере достижения самих изменений в породе.
В общем, суть та же, о которой говорилось здесь. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.
Можно добавить, что стандарт породы содержит, кроме самого требования, еще и допустимое отклонение (допустимый диапазон изменчивости).
💬 While software architects are interested in exploring evolutionary architectures, we aren’t attempting to model biological evolution. Theoretically, we could build an architecture that randomly changed one of its bits (mutation) and redeployed itself. After a few million years, we would likely have a very interesting architecture. However, we don’t have millions of years to wait.
We want our architecture to evolve in a guided way, so we place constraints on different aspects of the architecture to reign in undesirable evolutionary directions. A good example is dog breeding: By selecting the characteristics we want, we can create a vast number of different shaped canines in a relatively short amount of time.
Что интересно в этой фразе? А интересно здесь то, что в кинологии:
💬 По мере возникновения исторических изменений в породе в стандарт могут вносится корректировки.
💬 Стандарт периодически пересматривают и изменяют, что обеспечивает прогресс породы
-- Википедия.
Прошу простить за адресацию к Википедии - всё-таки я не кинолог и не зоотехник 🙂) Последняя цитата взята из http://www.kgau.ru/distance/zif_03/razvedenie-110401/07_01.html - вроде заслуживает доверия.
Ключевой момент - изменения в стандарт вносятся не только по мере выявления желаемых свойств породы, но и по мере достижения самих изменений в породе.
В общем, суть та же, о которой говорилось здесь. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.
Можно добавить, что стандарт породы содержит, кроме самого требования, еще и допустимое отклонение (допустимый диапазон изменчивости).
Wikipedia
Стандарт породы
Станда́рт поро́ды — документ, подробно описывающий важные характеристики и параметры животного, его экстерьерные и другие признаки.
👍5🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Пообщался со @schetinnikov . Выяснилось, что он имеет преподавательский опыт и неплохие спикерские навыки. Глубоко знает проблематику DDD и умеет интересно вести дискуссию. Дискуссия настолько получилась увлекательной, что я предложил проводить подобные дискуссии…
Вебининар по EventSoursing.
Коллеги, помните, я писал про этого парня @schetinnikov ? В этот четверг он проведет вебинар про Event Sourcing, и расскажет, как внедряли его на практике, какие были подводные камни, какой результат был достигнут. Подробности здесь:
https://news.1rj.ru/str/ru_arc/278
P.S.: прошу поддержать репостом
P.S.S.: исправил ссылку на событие.
Коллеги, помните, я писал про этого парня @schetinnikov ? В этот четверг он проведет вебинар про Event Sourcing, и расскажет, как внедряли его на практике, какие были подводные камни, какой результат был достигнут. Подробности здесь:
https://news.1rj.ru/str/ru_arc/278
P.S.: прошу поддержать репостом
P.S.S.: исправил ссылку на событие.
Telegram
Russian Association of Software Architects
Event Sourcing — это паттерн проектирования в информационных системах, который заключается в сохранении состояния системы путем сохранения истории всех событий, происходящих в системе.
Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет…
Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет…
🔥9👍7
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных (Denis Beskov)
Мы перевели первые 5 глав миникниги
Влада Хононова What is Domain-Driven Design?
https://systems.education/what-is-domain-driven-design
Книга поможет разработчикам, аналитикам, архитекторам познакомиться с основными понятиями и концепциями DDD, прежде чем нырять в него глубоко.
Глава 1. Анализ предметных областей
Что такое предметная область?
Что такое предметная подобласть?
Типы подобластей
Основные предметные подобласти
Сложность и скорость изменений
Практические аспекты реализации
Сущность основных предметных подобластей
Обобщённые предметные подобласти
Практические аспекты реализации
Сложность и скорость изменений
Практические аспекты реализации
Кто такие эксперты предметной области?
Заключение
Глава 2. Изучение знаний о предметной области
Поиск знаний
Коммуникация
Что такое единый язык?
Язык бизнеса
Согласованность
Модель предметной области
Что такое модель?
Эффективное моделирование
Моделирование предметной области
Постоянная работа
Заключение
Глава 3. Управление сложностью при помощи ограниченного контекста
Несогласованные модели
Что такое ограниченные контекст?
Ограниченный контекст
Границы модели
Объем ограниченного контекста
Ограниченные контексты против предметных областей
Предметные подобласти
Ограниченные контексты
Взаимодействие между предметными подобластями и ограниченными контекстами
Физические границы
Границы владения
Заключение
Глава 4. Сопоставление контекстов
Сотрудничество
Партнёрство
Общее ядро
Одна команда владеет несколькими ограниченными контекстами
Заказчик-поставщик
Конформизм
Паттерн предохранительного уровня
Сервис с открытым протоколом
Раздельные пути
Проблемы коммуникации
Универсальная подобласть
Различия моделей
Когда избегать
Карта контекста
Заключение
Глава 5. Паттерны реализации бизнес-логики
Транзакционный сценарий
Активная запись
Модель предметной области
Реализация
Реализация
Сложность
Единый язык
Строительные блоки
Объект-значение
Реализация
Агрегат
Согласованность
Граница транзакции
Иерархия объектов
Ссылка на другие агрегаты
Корень агрегата
События предметной области
Другие строительные блоки
Модель предметной области, основанная на событиях
Источник событий
Источник истины
Преимущества
Заключение
#архитектура #книги #переводы
Влада Хононова What is Domain-Driven Design?
https://systems.education/what-is-domain-driven-design
Книга поможет разработчикам, аналитикам, архитекторам познакомиться с основными понятиями и концепциями DDD, прежде чем нырять в него глубоко.
Глава 1. Анализ предметных областей
Что такое предметная область?
Что такое предметная подобласть?
Типы подобластей
Основные предметные подобласти
Сложность и скорость изменений
Практические аспекты реализации
Сущность основных предметных подобластей
Обобщённые предметные подобласти
Практические аспекты реализации
Сложность и скорость изменений
Практические аспекты реализации
Кто такие эксперты предметной области?
Заключение
Глава 2. Изучение знаний о предметной области
Поиск знаний
Коммуникация
Что такое единый язык?
Язык бизнеса
Согласованность
Модель предметной области
Что такое модель?
Эффективное моделирование
Моделирование предметной области
Постоянная работа
Заключение
Глава 3. Управление сложностью при помощи ограниченного контекста
Несогласованные модели
Что такое ограниченные контекст?
Ограниченный контекст
Границы модели
Объем ограниченного контекста
Ограниченные контексты против предметных областей
Предметные подобласти
Ограниченные контексты
Взаимодействие между предметными подобластями и ограниченными контекстами
Физические границы
Границы владения
Заключение
Глава 4. Сопоставление контекстов
Сотрудничество
Партнёрство
Общее ядро
Одна команда владеет несколькими ограниченными контекстами
Заказчик-поставщик
Конформизм
Паттерн предохранительного уровня
Сервис с открытым протоколом
Раздельные пути
Проблемы коммуникации
Универсальная подобласть
Различия моделей
Когда избегать
Карта контекста
Заключение
Глава 5. Паттерны реализации бизнес-логики
Транзакционный сценарий
Активная запись
Модель предметной области
Реализация
Реализация
Сложность
Единый язык
Строительные блоки
Объект-значение
Реализация
Агрегат
Согласованность
Граница транзакции
Иерархия объектов
Ссылка на другие агрегаты
Корень агрегата
События предметной области
Другие строительные блоки
Модель предметной области, основанная на событиях
Источник событий
Источник истины
Преимущества
Заключение
#архитектура #книги #переводы
systems.education
■ [Перевод книги] Влад Хононов. Что такое предметно-ориентированное проектирование?
Введение в Domain-Driven Design
🔥32❤4👍2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
В среду в 20:00 обсудим на online встрече роль архитектора в Agile-разработке:
1. Какие ключевые отличия Agile от других моделей разработки.
2. Какие архитектурные функции важны в Agile разработке.
3. Кто должен эти функции осуществлять.
4. Как должны быть организованы процессы проектирования архитектуры в Agile процессах.
Подключение по ссылке.
Событие в Google calendar по ссылке.
1. Какие ключевые отличия Agile от других моделей разработки.
2. Какие архитектурные функции важны в Agile разработке.
3. Кто должен эти функции осуществлять.
4. Как должны быть организованы процессы проектирования архитектуры в Agile процессах.
Подключение по ссылке.
Событие в Google calendar по ссылке.
Zoom Video
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution…
🔥8
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Какие темы вам интересны для следующих вебинаров? Напишите в комментариях 📝
Проголосуйте 👍 за тот комментарий, который отражает интересную для вас тему.
Проголосуйте 👍 за тот комментарий, который отражает интересную для вас тему.
Forwarded from Event Storming (Sergey Baranov)
Во вторник (10.10) в 19:00 проведу здесь стрим «Введение в Event Storming»
Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.
Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).
Like/Share 🙂
Он в большей степени для тех, кто хочет узнать что такое Event Storming:
- Основные сценарии использования
- Основные элементы
- Основные структуры
- Основные эффекты
- Основные артефакты, которые можно получить из модели Event Storming
- Ваши вопросы и мои ответы 🙂
Основной контент где-то на 40-50 минут, но так как это стрим, то тайминг не фиксирован.
Вопросы и ответы могут быть любой сложности, не обязательно из области «введения в Event Storming» (кстати, вопросы можно уже начинать задавать в виде комментариев к этому сообщению).
Like/Share 🙂
👍19🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
На текущий момент эта идея превосходит все мои ожидания по качеству своего материала. Наконец-то скоро появится статья (уже в финальной стадии) на тему моделирования и ограниченных контекстов, благодаря @StanislavBolsun . Статья освещает тот самый вопрос,…
Статья про доменную модель, о которой я говорил, опубликована:
https://dckms.github.io/system-architecture/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.html
Глубоко признателен @StanislavBolsun за авторство и за проделанный труд.
Есть идеи организовать по материалам статьи вебинар с автором.
https://dckms.github.io/system-architecture/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.html
Глубоко признателен @StanislavBolsun за авторство и за проделанный труд.
Есть идеи организовать по материалам статьи вебинар с автором.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
На текущий момент эта идея превосходит все мои ожидания по качеству своего материала. Наконец-то скоро появится статья (уже в финальной стадии) на тему моделирования и ограниченных контекстов, благодаря @StanislavBolsun . Статья освещает тот самый вопрос…
👍11🔥7❤2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Статья про доменную модель, о которой я говорил, опубликована: https://dckms.github.io/system-architecture/stanislav.bolsun/it/ddd/domain-model/domain-model-definition.html Глубоко признателен @StanislavBolsun за авторство и за проделанный труд. Есть идеи…
Создана группа для доработки статьи. Это хорошее событие, поскольку оно зарождает традицию научных дискуссий - давняя мечта одного моего давнего товарища.
Если кто-то хочет внести свой вклад, пишите мне в личку @emacsway - я добавлю в группу.
Если кто-то хочет внести свой вклад, пишите мне в личку @emacsway - я добавлю в группу.
Forwarded from Архитектура ИТ-решений
Вторая часть серии, на мой взгляд, оказалась заметно слабее первой. (Может тема такая). Тем не менее, я думаю, что оставшиеся две заметки:
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть
- DDD Aggregates: Consistency Boundary
- DDD Aggregates: Optimistic Concurrency
реабилитируют серию. Рекомендую их посмотреть
James Hickey
DDD Aggregates: Consistency Boundary
A consistency boundary helps us when we have business rules in our software that span multiple objects or have high contention. Let's dig down a bit deeper!
🎉2
Russian Association of Software Architects
В последнее время многие обсуждают DDD, но не все понимают что это такое. От этого страдает качество подобных обсуждений. И найти внятное определение DDD в литературе, действительно, непросто. Ниже приводится определение DDD от первоисточника: I. Putting…
Хочу поделиться выводами, возникшими в результате обсуждения статьи.
В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла.
Текст под картинкой гласит: "With a UBIQUITOUS LANGUAGE, conversations among developers, discussions among domain experts, and expressions in the code itself are all based on the same language, derived from a shared domain model."
Подчеркну: "shared domain model".
А также: "The model is the backbone of a language used by all team members. Because of the binding of model and implementation, developers can talk about the program in this language. They can communicate with domain experts without translation. And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself."
-- DDD by Eric Evans
Продолжение...
В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла.
Текст под картинкой гласит: "With a UBIQUITOUS LANGUAGE, conversations among developers, discussions among domain experts, and expressions in the code itself are all based on the same language, derived from a shared domain model."
Подчеркну: "shared domain model".
А также: "The model is the backbone of a language used by all team members. Because of the binding of model and implementation, developers can talk about the program in this language. They can communicate with domain experts without translation. And because the language is based on the model, our natural linguistic abilities can be turned to refining the model itself."
-- DDD by Eric Evans
Продолжение...
👍3🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Хочу поделиться выводами, возникшими в результате обсуждения статьи. В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла. …
Я продолжу.
В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space).
Свидетельство этого можно обнаружить, например, в спецификации ArchiMate: "Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology".
DDD отличается тем, что Application Model разделяет (shared) Business Model, что и образует ubiquitous language.
Обратите внимание, Event Stroming начинается с исследования предметной области (Big Picture), а заканчивается проектированием системы (Software Design или Modeling software systems) на той же самой диаграмме, которая после реализации практически 1:1 будет отражать структуру кода.
Можно даже не создавать никакой отдельной диаграммы (как и модели) для Application Layer:
💬 Work on the existing model. Modeling processes, injecting new concepts on top of the existing artifact works well in small groups scenario and/or when you have the possibility of a full-day (or more than one day) workshop.
-- Introducing EventStorming by Alberto Brandolini
💬 Big Picture workshop tried hard not to focus but to embrace the whole complexity and maximize learning. Now the starting point is different: * we can assume we have a shared better understanding of the underlying domain here the focus is on implementing software features that are solving a specific problem.
...
Here we are trying to find one or more solutions to a problem worth solving. This means that the workshop isn’t over until we have something that looks like a robust candidate solution.
...
the big picture was a model of our current level of understanding, by digging deeper into key interaction we are already making it obsolete.
-- Introducing EventStorming by Alberto Brandolini
💬 Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a fluent ubiquitous language.
-- DDD Reference by Eric Evans
Вот что скрывается за фразой ubiquitous language. Это, наверное, наиболее существенный отличительный признак DDD.
Продолжение...
В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space).
Свидетельство этого можно обнаружить, например, в спецификации ArchiMate: "Layers – the three levels at which an enterprise can be modeled in ArchiMate – Business, Application, and Technology".
DDD отличается тем, что Application Model разделяет (shared) Business Model, что и образует ubiquitous language.
Обратите внимание, Event Stroming начинается с исследования предметной области (Big Picture), а заканчивается проектированием системы (Software Design или Modeling software systems) на той же самой диаграмме, которая после реализации практически 1:1 будет отражать структуру кода.
Можно даже не создавать никакой отдельной диаграммы (как и модели) для Application Layer:
💬 Work on the existing model. Modeling processes, injecting new concepts on top of the existing artifact works well in small groups scenario and/or when you have the possibility of a full-day (or more than one day) workshop.
-- Introducing EventStorming by Alberto Brandolini
💬 Big Picture workshop tried hard not to focus but to embrace the whole complexity and maximize learning. Now the starting point is different: * we can assume we have a shared better understanding of the underlying domain here the focus is on implementing software features that are solving a specific problem.
...
Here we are trying to find one or more solutions to a problem worth solving. This means that the workshop isn’t over until we have something that looks like a robust candidate solution.
...
the big picture was a model of our current level of understanding, by digging deeper into key interaction we are already making it obsolete.
-- Introducing EventStorming by Alberto Brandolini
💬 Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in software, even as you seek to make it reflect deeper insight into the domain. Demand a single model that serves both purposes well, in addition to supporting a fluent ubiquitous language.
-- DDD Reference by Eric Evans
Вот что скрывается за фразой ubiquitous language. Это, наверное, наиболее существенный отличительный признак DDD.
Продолжение...
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Хочу поделиться выводами, возникшими в результате обсуждения статьи.
В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла.…
В каноническом определении DDD я недооценивал третий пункт: "Speak a ubiquitous language within an explicitly bounded context." За этой скромной фразой не видно всей глубины её смысла.…
👍4🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Я продолжу. В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space). Свидетельство этого можно обнаружить, например…
Что такое модель по SEBoK:
🔷 https://sebokwiki.org/wiki/Model_(glossary)
🔷 https://sebokwiki.org/wiki/What_is_a_Model%3F
🔷 https://sebokwiki.org/wiki/Types_of_Models
🔷 https://sebokwiki.org/wiki/Why_Model%3F
Что такое концептуальная модель:
🔷 https://sebokwiki.org/wiki/System_Modeling_Concepts#Conceptual_Model
🔷 https://sebokwiki.org/wiki/Concept_(glossary)
См. также...
🔷 https://sebokwiki.org/wiki/Model_(glossary)
🔷 https://sebokwiki.org/wiki/What_is_a_Model%3F
🔷 https://sebokwiki.org/wiki/Types_of_Models
🔷 https://sebokwiki.org/wiki/Why_Model%3F
Что такое концептуальная модель:
🔷 https://sebokwiki.org/wiki/System_Modeling_Concepts#Conceptual_Model
🔷 https://sebokwiki.org/wiki/Concept_(glossary)
См. также...
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Eric Evans дает интересное определение Constantine's Law нетехническим языком:
💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подробности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.
<...>
То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количественные критерии, по которым их якобы можно измерить, подсчитав количество ассоциаций и взаимодействий. Но это не просто механические характеристики подразделения кода на модули, а идейные концепции. Человек не может одновременно удерживать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).
MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.
<...>
It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового
#SoftwareDesign
💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подробности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.
<...>
То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количественные критерии, по которым их якобы можно измерить, подсчитав количество ассоциаций и взаимодействий. Но это не просто механические характеристики подразделения кода на модули, а идейные концепции. Человек не может одновременно удерживать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).
MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.
<...>
It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового
#SoftwareDesign
👍1
Forwarded from Архитектура ИТ-решений
В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide
👍3
Forwarded from Stanislav Bolsun
When you are just getting started in your software modeling efforts, your Bounded Context is
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your
solution space , with your software model being reflected as project source code. (The problem
space and solution space are better explained in the box.) Remember that a Bounded Context is
where a model is implemented, and you will have separate software artifacts for each Bounded
Context.
и
The best Ubiquitous Language will be developed by a collaborative feedback loop
that drives out the combined mental model of the team. Open conversation, exploration, and
challenges to your current knowledge base result in deeper insights about the Core Domain.
интересная мысль у Вернона в distilling DDD
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your
solution space , with your software model being reflected as project source code. (The problem
space and solution space are better explained in the box.) Remember that a Bounded Context is
where a model is implemented, and you will have separate software artifacts for each Bounded
Context.
и
The best Ubiquitous Language will be developed by a collaborative feedback loop
that drives out the combined mental model of the team. Open conversation, exploration, and
challenges to your current knowledge base result in deeper insights about the Core Domain.
интересная мысль у Вернона в distilling DDD
🔥3