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

💬 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

В той же книге:

💬 Chapter 6. Too Much to Do

When you are overloaded, don't think of it as not having enough time; think of it as having too much to do. You can't give yourself more time, but you can give yourself less to do, at least for the moment.

We were on a project together once that the team had rescued from impending oblivion. Toward the first release there came a time when it was clear to everyone that we weren't going to make the release date. One day we had a stand-up meeting to discuss the problem. We went around the circle answering the question "What is preventing us from going into production?"

"I don't have enough time."

"I don't have enough time."

"I don't have enough time."

Nobody had enough time. But there was no obvious answer. Everybody went home.

Over Korean food that night (we always ate Korean; it seems to be good for the brain), we were talking about the meeting. Suddenly a cosmic ray collided with a piece of kimchee and we saw the real problem.

The next morning we called another stand-up.

"Repeat after me—I have too much to do."

Shrugs all around, but what the heck.

"I have too much to do."

"I have too much to do."

"I have too much to do."

And so on around the circle until we got to Richard.

"I have too much to do. What is your point?"

The point is that when you don't have enough time you are out of luck. You can't make more time. Not having enough time is a position of hopelessness. And hopelessness breeds frustration, mistakes, burnout, and failure.

Having too much to do, however, is a situation we all know. When you have too much to do you can:

- Prioritize and not do some things
- Reduce the size of some of the things you do
- Ask someone else to do some things

Having too much to do breeds hope. We may not like being there, but at least we know
what to do.

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

Вот зачем нужно планирование.

Тут возникло предположение о том, что Agile и планирование несовместимы.

Я не буду сейчас говорить о том, что сегодня Agile в чистом виде стремительно снижает свою долю на рынке в пользу гибридных моделей разработки. Хотя на этом можно было бы и остановиться, потому что:

💬 An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.
-- AgileImposition by MartinFowler (один из ключевых соорганизаторов Agile Manifesto)

Раз уж затронули этого фигуранта Agile Manifesto, то давайте выслушаем его полностью:

💬 Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.

Agile plans are a baseline that we use to help us control changes. Agile teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software.

Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.

Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team's effectiveness, but are always second-order influences.
-- Agile Software Guide by Martin Fowler

💬 The problem with predictive processes is that project quality is measured by conformance to plan. This makes it difficult for people to signal when reality and the plan diverge. The common result is a big slip in the schedule late in the project. In an agile project there is a constant reworking of the plan with every iteration.
-- New Methodology by Martin Fowler

💬 A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.
-- New Methodology by Martin Fowler

Из этого видно, что ключевым в Agile является не отсутствие плана, а отсутствие следования плану, точнее, присутствие изменяемости плана с каждым новым инкрементом знаний, возникающим в результате практического исследования каждого нового системного инкремента. Подробнее смотрите в главе "Predictive and Adaptive Planning" его книги "UML Distilled" 3d edition.

Задача Agile заключается не в устранении плана, а в компенсации трудности заблаговременно планирования путем использования эмпирического способа обработки неопределенности (т.е. путем adaptation, responding).

При этом нужно учитывать, что адаптация тоже имеет свою стоимость, и важно находить баланс между экономической целесообразностью Prediction и Adaptation, о чем шла речь здесь:
https://news.1rj.ru/str/ru_arc/50

Иными словами, адаптации должно быть настолько мало, насколько недорого обходится Prediction. Вот что по этому поводу говорит сам организатор Agile Manifesto:

💬 The cost of improving the estimate, the initial work breakdown estimation, the cost of refining that grows exponentially. With every next layer you want to take it down. And the benefit of doing that does not grow exponentially. It grows logarithmically."
—"YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)" at 33:15

А поскольку тут собрались главным образом архитекторы, то, дабы не впасть в Культ Карго, возникает вопрос, а какую проблему решает Agile? Вот здесь перечислен список решаемых им проблем: https://news.1rj.ru/str/ru_arc/288

Это список является причиной появления Agile на свет, и если вдруг в какой-то компании список этих проблем не решается, то значит применение Agile в текущем виде лишено своего основного смысла.

Обратите внимание на эти пункты:

Customers are afraid that:
- They won't ever see a meaningful plan.
- The plans they do see will be fairy tales.

Собственно говоря, в основу Agile Manifesto положен документ Bill of Rights:
- https://news.1rj.ru/str/ru_arc_chat/15572

И ключевую роль в появлении философско-психологической составляющей Agile сыграла эрудированность Kent Beck в вопросах психологи, философии и менеджмента. Кстати, именно от него заразился этими идеями Robert Martin, который и организовал встречу Agile Manifesto. Я уже цитировал позицию Kent Beck по вопросу планирования:
- https://news.1rj.ru/str/emacsway_log/1221
- https://news.1rj.ru/str/emacsway_log/1222

Добавлю еще одно его выражение, которое идеально отвечает на вопрос по сути обсуждения:

💬 Like so many, we enjoy Eisenhower's quotation: "In preparing for battle I have always found that plans are useless, but planning is indispensable." [Richard Nixon, Six Crises (New York: Touchstone Press, 1990)] That's why this isn't a book about plans; it's about planning. And planning is so valuable and important, so vital, that it deserves to go on a little every day, as long as development lasts.
-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

Это говорит Kent Beck, основатель XP - одной из первых и наиболее успешных Agile методологий, практики которой использует подавляющее большинство современных методологий.