В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide

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

В этом тексте Vaughn Vernon поясняет, почему Domain Model по своему названию относится к области проблемы, а на самом деле - к области решения. В общем, он подтверждает правильность моих выводов.

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

Как вы считаете, какие последствия наступают, если команда не понимает, что такое модель, как её формировать и определять её границы? Нужна ли вообще вся эта "академичность"? Живут же как-то без этого... Напишите своё мнение.

💬 The traditional software development lifecycle implies the following translations:

- Domain knowledge into an analysis model
- Analysis model into requirements
- Requirements into system design
- System design into source code

Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.

...

Modeling the Business Domain

When cultivating a ubiquitous language, we are effectively building a model of the business domain. The model is supposed to capture the domain experts’ mental models—their thought processes about how the business works to implement its function. The model has to reflect the involved business entities and their behavior, cause and effect relationships, and invariants.

The ubiquitous language we use is not supposed to cover every possible detail of the domain. That would be equivalent to making every stakeholder a domain expert. Instead, the model is supposed to include just enough aspects of the business domain to make it possible to implement the required system; that is, to address the specific problem the software is intended to solve. In the following chapters, you will see how the ubiquitous language can drive low-level design and implementation decisions.

-- Learning DDD by Vladik Khononov

В 2022 году я думал, как хорошо, что в РФ есть такая компания как Яндекс, которая обеспечивает технологическую независимость страны. Как я тогда ошибался. Нет ничего хуже монополии в условиях безальтернативности, которая приводит к полной зависимости от прихоти монополиста. Про цены на Яндекс.Такси, который выкупил почти всех своих ключевых конкурентов, на сегодняшний день не написал только ленивый. Яндекс.Такси вверг меня в середину 90-х - бордюрщики и заказы по телефону местячкового такси по спальному району Москвы вновь стали обычной практикой в то время, как человечество научилось управлять транспортным средством силой мысли. Прогресс корпорации Яндекс налицо. Но еще больше меня поразило не это.

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

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

Извините за оффтоп.

Что такое оценка? Как её выразить? Очень хорошая краткая статья:
"How to Read Lead Time Distribution" by Mauvisoft Team

💬 Simplicity is the ultimate sophistication.
-- Leonardo da Vinci

Не смог не купить 🙂

очень подробно описано все в книге - Domain Modeling Made Functional
(про ДДД)

Understanding the problem doesn’t mean that building a solution is easy. The solution can’t possibly represent all the information in the original domain, nor would we want it to. We should only capture the information that is rele- vant to solving a particular problem. Everything else is irrelevant.
We therefore need to create a distinction between a “problem space” and a “solution space,” and they must be treated as two different things. To build the solution we will create a model of the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space as shown in the figure on page 17.

---

That means that things in our design must represent real things in the domain expert’s mental model. That is, if the domain expert calls something an “order,” then we should have something called an Order in the code that corresponds to it and that behaves the same way.
And conversely, we should not have things in our design that do not represent something in the domain expert’s model. That means no terms like OrderFactory, OrderManager, OrderHelper, and so forth. A domain expert wouldn’t know what you meant by these words. Of course, some technical terms will have to occur in the codebase, but you should avoid exposing them as part of the design.
The set of concepts and vocabulary that is shared between everyone on the team is called the Ubiquitous Language—the “everywhere language.” This is the language that defines the shared mental model for the business domain. And, as its name implies, this language should used everywhere in the project, not just in the requirements but in the design and, most importantly, in the source code.

In the first chapter, when we were talking about the importance of a shared mental model, we emphasized that the code must also reflect this shared model and that a developer should not have to do lossy translations between the domain model and the source code.

Это очень важная информация, которая, к сожалению, очень слабо освещена и многим непонятна. Как результат - очень многие не понимают о том, что такое DDD и зачем он вообще нужен. Практически никто не может объяснить своими словами что такое DDD (на самом деле почти никто не может даже привести формальное определение, которое не сильно добавляет ясности).

Слова Scott Wlaschin - ещё один источник, подтверждающий правильность моих выводов, озвученных ранее.

DDD - это сокращение дивергенции между ментальной (концептуальной) моделью и моделью решения. По сути дела, это их объединение, т.е. построение модели решения на подмножестве ментальной модели, и именно это и называется ubiquitous language.

Taiga переписан на актуальной версии Django и Angular:
https://github.com/taigaio/taiga

Если вдруг кто пощупает вживую, поделитесь отзывом, пожалуйста.

Общался на днях со своим коллегой - невероятно грамотным человеком. И он помог мне сделать для себя открытие.

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

Пропущу длинную цепочку умозаключений, скажу только вывод. Пытаться "продать" решение в таком случае, действительно, может оказаться бесполезно. Вместо этого нужно наладить планирование разработки. Да, пусть план будет долгим, корявым и неточным, но он должен быть, т.к. именно он может снять те самые когнитивные искажения, на основе которых формируются иррациональные решения ЛПР.

Животворящая книга в этом вопросе - это "Planning Extreme Programming" by Kent Beck, Martin Fowler, которая хорошо раскрывает тему о том, почему бесполезно убеждать ЛПР в условиях отсутствия планирования.

[UPDATE]: об инструментах планирования:
- https://news.1rj.ru/str/emacsway_log/1079
- https://news.1rj.ru/str/emacsway_log/1081
- https://news.1rj.ru/str/emacsway_log/1098

О методах планирования и оценивания:
- https://news.1rj.ru/str/emacsway_log/916

В продолжение темы планирования.

Вот что пишет Дейл Карнеги в своей книге "Как перестать беспокоиться":

💬 Сорок два года спустя, в тихий весенний вечер, когда в университетском парке цвели тюльпаны, сэр Уильям Ослер обратился к студентам Йельского университета. Считается, сказал он, что такой человек, как он,- профессор четырех университетов и автор популярной книги, должен обладать «мозгом особого качества». Это неверно, заявил он. Оказывается, и его близкие друзья знали, что он обладал «самыми посредственными способностями». В чем же секрет его успеха? Он сказал, что достиг успеха потому, что стремился жить в отсеке сегодняшнего дня, непроницаемо отгороженном от остальных дней. Что он имел в виду? За несколько месяцев до своего выступления в Йельском университете сэр Уильям Ослер пересек Атлантический океан на большом океанском лайнере, на котором капитан, стоявший на мостике, мог нажать на кнопку, и сразу же слышался шум механизмов, и отдельные отсеки корабля начинали герметически закрываться, чтобы в них не попала вода. «Каждый из вас,- сказал доктор Ослер этим студентам,- является гораздо более замечательным механизмом, чем гигантский лайнер, и, вступив в жизнь, вы отправляетесь в более длительное плавание. Я настаиваю на том, что вы должны научиться контролировать данный вам механизм и защищать его от штормов, то есть вовремя изолировать его отдельные отсеки. Только тогда вы обеспечите безопасность своего путешествия. Стойте на мостике и обеспечьте, чтобы хотя бы главные переборки корабля находились в рабочем состоянии. Нажмите на кнопку, и вы услышите, как на каждом этапе вашей жизни железные двери изолируют от вас прошлое - мертвые вчерашние дни. Нажмите на другую кнопку, и металлический занавес изолирует будущее - не родившиеся завтрашние дни. Тогда вы в полной безопасности - на сегодняшний день!.. Изолируйте прошлое! Пусть мертвое прошлое хоронит своих мертвецов... Изолируйте вчерашние дни, которые освещали глупцам путь к могиле. Груз будущего, прибавленный к грузу прошлого, который вы взваливаете на себя в настоящем, заставляет спотыкаться на пути даже самых сильных. Изолируйте будущее так же герметически, как прошлое... Будущее в настоящем... Нет завтра. День спасения человека - сегодня. Бессмысленная трата энергии, душевные страдания, нервное беспокойство неотступно следуют по пятам человека, который беспокоится о будущем... Итак, закройте наглухо все отсеки корабля, отделите носовую и кормовую части лайнера железными переборками. Воспитывайте у себя привычку жить в отрезке времени, отделенном от прошлого и будущего „герметическими переборками".

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

-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.

И еще одна выдержка из той же книги:

💬 Один военный врач дал мне совет, который полностью преобразил мою жизнь. После тщательного осмотра он пришел к выводу, что в основе моих заболеваний было расстройство психики. «Тед, - сказал он, - я хочу, чтобы ты смотрел на свою жизнь, как на песочные часы. Ты знаешь, что тысячи песчинок находятся в верхней части песочных часов; и все они медленно и регулярно проходят через узкую перемычку посередине. Если ты или я сделаем так, чтобы через это отверстие в определенное время проходило больше, чем одна песчинка, часы испортятся. Ты, я и все остальные люди похожи на эти песочные часы. Когда мы утром встаем, возникают сотни дел, которые мы должны выполнить в этот день. И если мы не будем выполнять эти дела по одному в определенный промежуток времени (как одна песчинка проходит через узкое отверстие), а будем стремиться сделать все сразу, мы подорвем свои физические или психические силы».

Я применял эту философию на практике с того незабываемого дня, когда военный врач дал мне совет: «Одна песчинка - в единицу времени... Одно дело- в определенный промежуток времени». Этот совет спас меня физически и психически во время войны; он также помог мне теперь в мирное время. Я работаю клерком Коммерческой кредитной компании в Балтиморе.
В своей деятельности я столкнулся с теми же проблемами, которые возникали передо мной во время войны, - мне надо было выполнить очень много дел сразу, но в моем распоряжении было слишком мало времени, чтобы с ними справиться. Наши акции упали в цене. Нам надо было вводить в свою деятельность новые формы. В то время организовывались новые акционерные общества, которые открывались и закрывались, меняли адреса и т. п. Вместо того, чтобы раздражаться и нервничать, я вспомнил то, что мне говорил врач: «Одна песчинка - в единицу времени, одно дело - в определенный промежуток времени». Повторяя себе эти слова снова и снова, я выполнял свои обязанности наиболее рациональным образом. Делая свою работу, я больше не испытывал растерянности и замешательства, которые чуть не искалечили меня в боевых условиях».

Одним из самых ужасающих комментариев к нашему образу жизни является то, что почти половина коек в наших больницах занята пациентами, страдающими нервными и психическими расстройствами, пациентами, которых сломил непомерный груз накопившихся вчерашних дней и устрашающих завтрашних дней. Ведь значительное большинство этих людей могло бы спокойно наслаждаться жизнью и быть счастливыми и приносить пользу окружающим, если бы они следовали совету Иисуса Христа: «Не тревожьтесь о завтрашнем дне», или совету Уильяма Ослера: «Живите в „отсеке" сегодняшнего дня».

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

-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.

А вот что говорит по этому поводу Kent Beck:

💬 When Kent was about ten, he went fly-fishing for the first time in the Idaho panhandle. After a fruitless, sweaty day in pursuit of brook trout, he and his friends headed for home. After half an hour of stumbling through dense trees, they realized they were lost. Kent started to panic — fast breathing, tunnel vision, chills. Then someone suggested a plan — they would walk uphill until they hit a logging road they knew was up there. Instantly, the panic disappeared.

Kent was struck at the time by the importance of having a plan. Without the plan, he was going to do something stupid, or just go catatonic. With the plan he was calm again.

Plans in software development work the same way. If you know you have a tight deadline, but you make a plan and the plan says you can make the deadline, then you'll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.

But we've also seen plans lead to trouble. They can be a huge time sink, dragging days out of people who'd rather be doing something productive. Plans can be used as a stick to beat people with, and worst of all, they can conceal trouble until it's too late to deal with it.

-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

ЛПР, не имеющий уверенности в том, что он имеет достаточно ресурсов для выполнения требуемого объема работ до наступления контрольного срока, имеет склонность действовать эмоционально, а не рационально. Поэтому я и сказал, что любые рациональные доводы в таком состоянии имеют небольшие шансы быть услышанными. Хотите быть услышанным - дайте ЛПР уверенность в том, что его беспокоит, и продемонстрируйте это на примера плана. Ну или на примера плана докажите невозможность осуществления задумки. Если она невозможна, то и беспокоиться о ней тем более глупо. Человека изматывает неопределенность.

См. также https://news.1rj.ru/str/emacsway_log/771