VC - единственное, что запускалось на моей первой машинке - 386, 25мгц, 40 mb диск (и при этом 60 игр на нем было))).
Помню, как ковырял первые файлы через hiew, первые простенькие hello world’ы на ассемблере.
Первая цивилизация, ради которой в школе на перемене иногда бегал домой, - сделать хоть один ход, и быстро обратно.
Помню как ходили друг к другу с жесткими дисками, потому что это было на порядок быстрее, чем скопировать на нескольких дискетах, а на дисках надо было менять перемычки, чтобы порядок загрузки дисков указать и в BIOS поменять настройки.
Люблю такие посты, иногда приятно вспомнить беззаботные школьные времена, вернуться на мгновение на 30 лет назад :)
Да, там есть непростые нюансы, особенно, если какой-нибудь Event Sourcing используется:
Operational Stage: Secure Storage, Use, and Rotation During its active life, a key must be stored and used securely. Key Hierarchy: A common practice is to use Data-Encrypting Keys (DEKs) to encrypt cardholder data and protect those DEKs with stronger Key-Encrypting Keys (KEKs). Key Segregation: DEKs must be stored separately (physically or logically) from the data they protect, and KEKs must be stored separately from DEKs. Key Rotation: PCI DSS mandates that keys be replaced at the end of their defined cryptoperiod. This schedule should be based on risk, data sensitivity, and industry best practices. Simply rotating KEKs without rotating DEKs offers no real security benefit.
Да и мидла оно может даунгрейднуть, если только с ним работать. При серьезной разработке с нейронкой инженерии не меньше, а даже порой и больше, в том числе потому, что разработчику платить фикс в месяц, а количество требуемых токенов с развитием продукта растет, как и их стоимость. Есть разные варианты, безусловно, но все равно все упирается в фин модель, риски и инженерию.
Отдельная задача за время работы над ней вряд ли откатиться из типовой (если мы ее так определили) в исследовательскую, это достаточно редкая история. Скорее что-то такое найдем, что приведет к заведению новой исследовательской в процессе решения типовой. А вот если задачу оценили и она долго пролежала в беклоге, – здесь может быть все что угодно, и контекст изменяется непрерывно (как Вы верно заметили), и знания накапливаются.
Агрегат - это и есть сущность, но с инвариантом над некоторым кластером сущностей, входящих в него и не имеющим контекстуального смысла за его пределами.
Если пойти от обратного, то сущность - это агрегат, в котором определен инвариант только над ним самим и который не включает в себя других сущностей.
В ООП не будет примитивных set/get, будет конструктор и действия. Как только появляется явное изменение параметров - это уже не объект, но структура, и да, иногда их смешивают, что усложняет развитие «объекта+структуры данных».
Анемичной модели предметной области не существует по определению. Предметная область описывается объектами. Объект, по определению из ООД, определяется своим поведением и скрывает состояние. То, что не содержит поведения, а только структуры (чем и оперирует «анемичная модель») - это структура данных. Таким образом «анемичная модель» - это парадигма процедурного программирования, а DDD базируется на объектно-ориентированном дизайне, соответственно, «анемичная модель» в контексте к DDD не может быть определена.
VC - единственное, что запускалось на моей первой машинке - 386, 25мгц, 40 mb диск (и при этом 60 игр на нем было))).
Помню, как ковырял первые файлы через hiew, первые простенькие hello world’ы на ассемблере.
Первая цивилизация, ради которой в школе на перемене иногда бегал домой, - сделать хоть один ход, и быстро обратно.
Помню как ходили друг к другу с жесткими дисками, потому что это было на порядок быстрее, чем скопировать на нескольких дискетах, а на дисках надо было менять перемычки, чтобы порядок загрузки дисков указать и в BIOS поменять настройки.
Люблю такие посты, иногда приятно вспомнить беззаботные школьные времена, вернуться на мгновение на 30 лет назад :)
И у Марка Аврелия с Сенекой =)
Человеческая природа не сказать, что как-то фундаментально изменилась.
Привет!
Да, там есть непростые нюансы, особенно, если какой-нибудь Event Sourcing используется:
Operational Stage: Secure Storage, Use, and Rotation During its active life, a key must be stored and used securely. Key Hierarchy: A common practice is to use Data-Encrypting Keys (DEKs) to encrypt cardholder data and protect those DEKs with stronger Key-Encrypting Keys (KEKs). Key Segregation: DEKs must be stored separately (physically or logically) from the data they protect, and KEKs must be stored separately from DEKs. Key Rotation: PCI DSS mandates that keys be replaced at the end of their defined cryptoperiod. This schedule should be based on risk, data sensitivity, and industry best practices. Simply rotating KEKs without rotating DEKs offers no real security benefit.
Да и мидла оно может даунгрейднуть, если только с ним работать. При серьезной разработке с нейронкой инженерии не меньше, а даже порой и больше, в том числе потому, что разработчику платить фикс в месяц, а количество требуемых токенов с развитием продукта растет, как и их стоимость. Есть разные варианты, безусловно, но все равно все упирается в фин модель, риски и инженерию.
>> а) нижние уровни экзаменов без лабораторных тупо зазубривались (по книге, или по дампам)
Уже лучше, чем ничего :)
Отдельная задача за время работы над ней вряд ли откатиться из типовой (если мы ее так определили) в исследовательскую, это достаточно редкая история. Скорее что-то такое найдем, что приведет к заведению новой исследовательской в процессе решения типовой. А вот если задачу оценили и она долго пролежала в беклоге, – здесь может быть все что угодно, и контекст изменяется непрерывно (как Вы верно заметили), и знания накапливаются.
Агрегат - это и есть сущность, но с инвариантом над некоторым кластером сущностей, входящих в него и не имеющим контекстуального смысла за его пределами.
Если пойти от обратного, то сущность - это агрегат, в котором определен инвариант только над ним самим и который не включает в себя других сущностей.
В ООП не будет примитивных set/get, будет конструктор и действия. Как только появляется явное изменение параметров - это уже не объект, но структура, и да, иногда их смешивают, что усложняет развитие «объекта+структуры данных».
Анемичной модели предметной области не существует по определению. Предметная область описывается объектами. Объект, по определению из ООД, определяется своим поведением и скрывает состояние. То, что не содержит поведения, а только структуры (чем и оперирует «анемичная модель») - это структура данных. Таким образом «анемичная модель» - это парадигма процедурного программирования, а DDD базируется на объектно-ориентированном дизайне, соответственно, «анемичная модель» в контексте к DDD не может быть определена.