SOER

2021-09-22 12:27:43 Спасибо Хауди Хо за наводку про комментарии для постов, подключил чат для обсуждений, теперь должна появиться возможность комментировать оставленные сообщения. Открыть/Комментировать

2021-09-16 13:55:06 В чем причина разделения бизнес-логики и логики приложения в DDD?
Все дело в том, что бизнес-логика - это логика "реального" мира, на нее имеют влияние процессы, которые происходят за пределами "программы", поэтому причины и вектор развития бизнес-логики будут завязаны на "реальный мир", логика приложения же завязана исключительно на само приложение и изменение, и развитие будут происходить исключительно по внутренним причинам.

Так как темпы изменений и причины разные, то разделив логику приложения и бизнес-логику мы получим более гибкое решение, которое легче сопровождать и развивать.

Если же бизнес-логика и есть логика приложения (вырожденные случаи, когда мы разрабатываем приложение без бизнеса), то разделять их не имеет смысла. Открыть/Комментировать

2021-09-16 12:26:29 По поводу анемичных моделей надо помнить, что у нас есть совершенно разные "логики":
- бизнес-логика, независимая от приложения
- бизнес-логика, возникающая в следствие автоматизации (по сути создания приложения)
- логика приложения (по сути обязанность приложения обеспечивать свою работу)
- обязанность получения и доступа к данным (логика работы с данными)

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

2021-09-16 11:49:46 С DDD есть несколько нюансов, которые нужно помнить:
- DDD плохо ложится на Data Centric подход, т.е. если у вас простой CRUD+Rest вокруг него, то DDD скорее всего не нужен
- DDD не имеет смысла внедрять в маленьких приложениях, на самом деле если у вас порядка 30-40 User Stories, то это очень маленькое приложение, если начать делать его по DDD, то будет получен оверхед в виде ненужных Aggregate, Registry и Entities, куда проще использовать классический Transaction Script и сервисы. Открыть/Комментировать

2021-09-16 11:43:01 Чек-лист для проверки DDD архитектуры:
1) Проверка дизайна
существует несколько основных элементов домена, которые могут применяться для хранения стейта и реализации поведения:
- Entity, Value Object, Aggregate должны использоваться для хранения "стейта" и реализации "поведения"
- Data transfer Object - только "стейт"
- Service, Repository - только "поведение"
2) В DDD как правило используются следующие паттерны:
- Domain Object
- DTO
- Repository
- DAO
3) В DDD по возможности не должно быть:
- Анемичных моделей
- Fat Service
- Зацепления между разными Enteties Открыть/Комментировать

2021-08-03 18:43:31 Памятка по версионированию:
1. Наиболее распространено семантическое версионирование
MAJOR.MINOR.PATH-LABEL+MetaInfo
MAJOR - обратно несовместимые изменения
MINOR - обратно-совместимые изменения
PATCH - локальные изменения
2. Библиотеки при учете совместимости должны учитывать:
- бинарную совместимость
- семантическую совместимость (один и тот же код, должен должен приводить к одному и тому же результату)
- совместимость на уровне интерфейсов кода (один и тот же метод, должен иметь одну и ту же сигнатуру вызова)
Если хотя бы одно из условий нарушается - увеличивается MAJOR версия
3. API должны учитывать совместимость:
- по версии клиента (должен поддерживать все клиенты предыдущего API)
- по версии сервера (должен работать на серверах поддерживающих предыдущий API)
- по версии протокола (должен поддерживать все протоколы, что и предыдущий API)
Если хотя бы одно условие нарушается, увеличивается MAJOR версия.
4. Схемы данных
- При добавлении необязательных полей с дефолтным состоянием увеличивается MINOR
- При добавлении обязательных полей увеличивается MAJOR Открыть/Комментировать

2021-08-03 18:36:29 Открыть/Комментировать

2021-08-02 17:08:56 Доступ к API обычно осуществляется по следующей схеме Открыть/Комментировать

2021-08-02 11:27:08 - специализированные API - как правило API построенные на каком либо языке запросов, которые разрабатываются конкретно под сервер. Пример: SQL. Открыть/Комментировать

2021-08-02 11:26:01 - REpresentational State Transfer (REST) - набор прицнипов для построения легковесных API, как правило использует текстовый формат для обмена сообщениями (JSON, XML). Текстовый формат сообщений позволяет развязать зависимости сервера и клиента, не использовать какие-либо общие библиотеки. Унифицирован для веб-разработки. Открыть/Комментировать