Новый перевод от ArkadiyXIII:

- "Mapper Contexts и Supercontexts: Разделение domain-specific и domain-generic ограниченных контекстов"

#DDD #SoftwareArchitecture #SoftwareDesign #Microservices

"Software Design: Tidy First?" - новая книга, над которой работает Kent Beck. Читать главы можно уже сейчас:
- https://tidyfirst.substack.com/archive?sort=new

#SoftwareDesign

"Modeling Relationships in a DDD Way" by Vladimir Khorikov
- https://enterprisecraftsmanship.com/posts/modeling-relationships-in-ddd-way/?__s=dqpdv6io8bhfhi1pm82y

Хорошая статья, но самый интересный вопрос остался неосвещенным:

> The problem is that it’s hard to decide which side of a many-to-many relation is the owner of that relation.

#DDD #SoftwareDesign

Возвращаясь к определению Bounded Context от Alberto Brandolini:

"A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views."

, невольно начинаю думать, что перевод "Ограниченный" полисемантического слова "Bounded" , возможно, был выбран не совсем удачно. Есть предположение, что термин "Связанный" контекст лучше передает смысл.

На такую же мысль меня наводят и фразы:

"Bounded context means different models of the same thing (e.g., books, customers, etc.) and is represented by models and software that implement those models."

Иными словами, Bounded Context образует связанность между программируемой моделью и её сущностью реального мира.

Следующие две фразы трактуют термин "bounded" именно как "связанный":

"How to minimize inter-bounded context dependencies?"

"The components of complex systems are bounded sub-systems or agents that adapt or learn when they interact."

А следующая фраза говорит о том, чем именно "связаны" (т. е. скованы) команды. Кстати, слово "скованный" - один из вариантов перевода термина "bounded".

"The scope of each team was bounded by their business line and their products."

Следующие две фразы говорят о том, каким именно образом происходит "сковывание":

"Bounded contexts aligned with data source domains, such as fixed-income trading or consumer lending"

"Bounded contexts aligned with consumption domains, such as accounting or liquidity"

Эта идея немного рушится фразой:

"A bounded context is the boundary for the meaning of a model."

Но тут можно вспомнить, что термин "boundary" полисемантический, и означает также "межу" или "грань". Обратите внимание на фразу "boundary for the meaning". Не "boundary of subsystem", а "boundary for the meaning", что привязывает реализацию (solution space) к её "предметному смыслу" (meaning of a model). Т.е. главное не ограничить абы как подсистему, а привязать её к доменному толкованию. Именно это Alberto Brandolini и назвал "obligation to maintain integrity".

"bounded contexts delimit the applicability of domain models. As such, the bounded context is within the solution space."

Все цитаты из AO-S.

Что думаете? Какие мысли по этому поводу?

Старина Kent Beck написал очередную бомбовую статью про качественный код:
"Tune Software Development for Rate of Change, not Rate of Progress"
https://medium.com/@kentbeck_7670/tune-software-development-for-rate-of-change-not-rate-of-progress-56f93c15a769

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

#SoftwareDesign

Самое долгожданное событие в архитектурном мире наступило - материалы монументального многолетнего труда в области управления сложностью, одного из лучших авторов современности Vladik Khononov ( @vladik_kh ) начали выходить в публичность:
- https://youtu.be/d6BeLhm3a0s

Предыдущая его книга стала самой понятной и популярной в области DDD. До появления его книги разобраться с трудами Эванса и Вернона можно было только ценой титанических усилий, что сдерживало распространение DDD.

Новая его книга консолидирует труды Larry Constantine, Tom DeMarco, Meilir Page-Jones, David L. Parnas, Robert C. Martin, и вооружает нас принципом, способным легко отыскивать победные решения в задачах любого уровня сложности.

[UPDATE]: Ждем вторую часть этого keynote с ddd europe - "fractal geometry of software design". Через пару месяцев должны опубликовать.

#SoftwareDesign #MSA #DDD #SoftwareArchitecture

💬 "The Single Responsibility Principle (SRP):

Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times."
-- Robert C. Martin. Самая последняя редакция от 2022-07-06.

P.S.: Если вдруг кто еще считает, что SRP - это делать одну вещь...

#SoftwareDesign

Eric Evens в своей синей книге пишет, что, в общем-то не очень хорошо, когда Specification Pattern осведомлен об SQL

💬 "Now this design has some problems. Most important, the details of the table structure have leaked into the DOMAIN LAYER ; they should be isolated in a mapping layer that relates the domain objects to the relational tables. Implicitly duplicating that information here could hurt the modifiability and maintainability of the Invoice and Customer objects, because any change to their mappings now have to be tracked in more than one place. But this example is a simple illustration of how to keep the rule in just one place. Some object-relational mapping frameworks provide the means to express such a query in terms of the model objects and attributes, generating the actual SQL in the infrastructure layer. This would let us have our cake and eat it too."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

В C# для этого есть мощный механизм Expression Tree, что значительно упрощает дело. Примеры хорошо демонстрирует Vladimir Khorikov:
- https://enterprisecraftsmanship.com/posts/specification-pattern-c-implementation/
- https://enterprisecraftsmanship.com/posts/specification-pattern-always-valid-domain-model/
- https://github.com/vkhorikov/SpecificationPattern
- https://github.com/vkhorikov/SpecPattern

В Golang дело немного усложняется отсутствием нативной поддержки Expression Tree, и поддержку этих функций приходится брать на себя.

В общем, как получилась первая итерация (пока еще не финал), можно посмотреть здесь:

Абстрактная реализация + inMemory evaluator:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/seedwork/specification/

Конкретная реализация inMemory evaluator без использования рефлекции:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/endorser/specifications.go

Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/specification/

Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/endorser/endorser_specifications.go

Заложена (но до конца не раскрыта) возможность просмотра коллекций сущностей внутри агрегата и поиск удовлетворения условия хотя бы одним из элементов коллекции.

#DDD #SoftwareDesign

Идея экспортера, предложенная by Allen Holub:
- https://www.infoworld.com/article/2072302/more-on-getters-and-setters.html
удачно ложится на полностью искапсулированный объект построения SQL-запроса:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/recognizer/insert_query.go

#DDD #OOP #SoftwareDesign

💬 "Sometimes, to improve performance, or more likely to tighten security, queries may be implemented on the server as stored procedures. In that case, the SPECIFICATION could carry only the parameters allowed by the stored procedure. For all that, there is no difference in the model between these various implementations. The choice of implementation is free except where specifically constrained by the model. The price comes in a more cumbersome way of writing and maintaining queries.

This discussion barely scratches the surface of the challenges of combining SPECIFICATIONS with databases, and I'll make no attempt to cover all the considerations that may arise. I just want to give a taste of the kind of choices that have to be made."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Вот так примерно отвечает интеллигентный человек на нечто подобное тому, что в свое время сделала компания LinguaLeo.

#DDD #SoftwareDesign

Программист тратит на написание кода не более 5% времени.

I Know What You Did Last Summer
An Investigation of How Developers Spend Their Time
Roberto Minelli, Andrea Mocci and Michele Lanza
REVEAL @ Faculty of Informatics — University of Lugano, Switzerland
https://www.inf.usi.ch/faculty/lanza/Downloads/Mine2015b.pdf

#SoftwareDesign

Коллеги, в архитекторских кругах в свое время активно обсуждалась статья https://ebanoe.it/2016/07/20/shitcoders/ , и я недавно в очередной раз имел возможность убедиться в её достоверности.

Именно по этой причине я всегда избегал заказную разработку (под этим термином я не разделяю outsource и outstaff) и предпочитал работать на продуктах.

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

Но заказная разработка отличается от обычного legacy-проекта двумя критериями:
1. Подрядчик кровно заинтересован в поддержании низкого качества и в переусложнении, т.е. это позволяет ему продавать больше часов. Еще Edsger W. Dijkstra говорил: "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.". А это уже проблема не архитектурная, и я не знал, как её решить.
2. Малоразмерные проекты (основная ниша заказной разработки) никогда не обладали карьерной привлекательностью для высококвалифицированных специалистов, поэтому они всегда испытывали квалификационный голод. Эта проблема тоже не архитектурная.

Не зная, как решить проблему, я предпочитал обходить её стороной.

Но случилось так, что в силу жизненных обстоятельств я соприкоснулся с заказной разработкой. Подискутировав с Владиком Хононовым и с девушкой по имени Марина, у меня родилось понимание того, как эту проблему можно решить. И не просто решить её, а превратить решение этой проблемы в коммерческий проект.

Не берусь судить хватит ли у меня средств и упорства осуществить это решение на практике, но эта цель меня заинтересовала и я серьезно задумался о её осуществлении.

#Management #SoftwareDesign #Goal

Бесподобная статья о legacy от Mathias Verraes "Software design is just theory".

Знакомы фразы?
- “Software design is just theory.”
- “Design patterns are too academic.”
- “Writing code is the only way to become a better programmer.”
- “Just ship it.”
- “That’s over-designed.”

Меткое выражение проблемы (даже Matthew Skelton оценил):
💬 "We have created outsourcing farms, that produce legacy at the speed of typing. It’s legacy as a service (LaaS) [Quote by Pieter Hintjens]"

💬 "Software design has a slow feedback cycle. It takes a long time before your design starts biting you in the butt."

Теория - это обобщенная практика:
💬 "Their ideas are not “just theory”. It’s years of accumulated practice and insights. They work — often in many different contexts. We’re lucky: we can build on top of their ideas."

💬 "Learning is the bottleneck [Ashley Johnson]"

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

#SoftwareDesign #Legacy

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

# \d permission
Table "trac.permission"
Column | Type | Collation | Nullable | Default
----------+------+-----------+----------+---------
username | text | | not null |
action | text | | not null |
Indexes:
"permission_pk" PRIMARY KEY, btree (username, action)


Trac не перестает удивлять. Если бы не документация, то вряд ли догадался бы. Простота, с которой авторы Trac решают сложные задачи, шедевральна. Нечасто можно встретить, когда так мало кода делает так много. Гораздо чаще приходится наблюдать гораздо большее количество таблиц, которые не реализуют вообще никакого наследования, не говоря уже о множественном наследовании.

💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

#Management #SoftwareDesign

🔷 "Architecture vs. Design" by George Fairbanks. Интересные размышления.

#SoftwareArchitecture #SoftwareDesign