Да и мидла оно может даунгрейднуть, если только с ним работать. При серьезной разработке с нейронкой инженерии не меньше, а даже порой и больше, в том числе потому, что разработчику платить фикс в месяц, а количество требуемых токенов с развитием продукта растет, как и их стоимость. Есть разные варианты, безусловно, но все равно все упирается в фин модель, риски и инженерию.
Отдельная задача за время работы над ней вряд ли откатиться из типовой (если мы ее так определили) в исследовательскую, это достаточно редкая история. Скорее что-то такое найдем, что приведет к заведению новой исследовательской в процессе решения типовой. А вот если задачу оценили и она долго пролежала в беклоге, – здесь может быть все что угодно, и контекст изменяется непрерывно (как Вы верно заметили), и знания накапливаются.
Агрегат - это и есть сущность, но с инвариантом над некоторым кластером сущностей, входящих в него и не имеющим контекстуального смысла за его пределами.
Если пойти от обратного, то сущность - это агрегат, в котором определен инвариант только над ним самим и который не включает в себя других сущностей.
В ООП не будет примитивных set/get, будет конструктор и действия. Как только появляется явное изменение параметров - это уже не объект, но структура, и да, иногда их смешивают, что усложняет развитие «объекта+структуры данных».
Анемичной модели предметной области не существует по определению. Предметная область описывается объектами. Объект, по определению из ООД, определяется своим поведением и скрывает состояние. То, что не содержит поведения, а только структуры (чем и оперирует «анемичная модель») - это структура данных. Таким образом «анемичная модель» - это парадигма процедурного программирования, а DDD базируется на объектно-ориентированном дизайне, соответственно, «анемичная модель» в контексте к DDD не может быть определена.
Information
Rating
5,522-nd
Location
Москва, Москва и Московская обл., Россия
Registered
Activity
Specialization
Технический директор, Архитектор программного обеспечения
Да и мидла оно может даунгрейднуть, если только с ним работать. При серьезной разработке с нейронкой инженерии не меньше, а даже порой и больше, в том числе потому, что разработчику платить фикс в месяц, а количество требуемых токенов с развитием продукта растет, как и их стоимость. Есть разные варианты, безусловно, но все равно все упирается в фин модель, риски и инженерию.
>> а) нижние уровни экзаменов без лабораторных тупо зазубривались (по книге, или по дампам)
Уже лучше, чем ничего :)
Отдельная задача за время работы над ней вряд ли откатиться из типовой (если мы ее так определили) в исследовательскую, это достаточно редкая история. Скорее что-то такое найдем, что приведет к заведению новой исследовательской в процессе решения типовой. А вот если задачу оценили и она долго пролежала в беклоге, – здесь может быть все что угодно, и контекст изменяется непрерывно (как Вы верно заметили), и знания накапливаются.
Агрегат - это и есть сущность, но с инвариантом над некоторым кластером сущностей, входящих в него и не имеющим контекстуального смысла за его пределами.
Если пойти от обратного, то сущность - это агрегат, в котором определен инвариант только над ним самим и который не включает в себя других сущностей.
В ООП не будет примитивных set/get, будет конструктор и действия. Как только появляется явное изменение параметров - это уже не объект, но структура, и да, иногда их смешивают, что усложняет развитие «объекта+структуры данных».
Анемичной модели предметной области не существует по определению. Предметная область описывается объектами. Объект, по определению из ООД, определяется своим поведением и скрывает состояние. То, что не содержит поведения, а только структуры (чем и оперирует «анемичная модель») - это структура данных. Таким образом «анемичная модель» - это парадигма процедурного программирования, а DDD базируется на объектно-ориентированном дизайне, соответственно, «анемичная модель» в контексте к DDD не может быть определена.