Golang DDD реализация зависимых модулей

Я пытаюсь внедрить DDD-архитектуру в свои прикладные модули и встать с проблемой хранения похожих (зависимых) структур между ними.Golang DDD реализация зависимых модулей

В первом пакете я хранить все, что связано с организацией Люди: Услуги (Хранилища), контроллеры, модели и т.д. ...

Во втором пакете хранить все, что связано с другим объектом Квартира: Услуги (Хранилища), контроллеры, модель и т.д. ...

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

Некоторых квартира пакета услуги должны быть в состоянии назвать такие методы, как получить/обновление/... Арендаторов. Я бы с удовольствием не повторно реализовать эти действия и используйте их из реализаций в Людях пакета PeopleService, но эта служба возвращает People объекта, а не Арендатора.

Должен ли я создать дополнительную структуру (копировать-вставить весь исходный код) Люди в апартаменты пакет , назовем его Арендатором и преобразования типов возвращаемых из PeopleService к нему?

Или есть другой способ сделать это?

Кроме того, где я должен хранить интерфейсы служб/репозиториев (интерфейсы с подобными CRUD-методам) конкретного объекта? Если интерфейс PeopleService будет как в Люди и Квартира пакеты?

Спасибо.

источник

2016-09-15 i.van

DDD - это не архитектура. DDD не имеет ничего общего с CRUD.Если вы можете просто скопировать-вставить код между сущностями и службами, с которыми вы имеете дело с CRUD, вам вообще не нужен DDD и модель домена. Получите генератор приложений CRUD и сделайте это. – plalx

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

я бы, наверное, сделать это таким образом:

Отделить все связанные модели в отдельных пакетах models.
Использовать композицию для людей-> Арендаторов, например. type Person { Name string } type Tenant struct { Person }
С уважением Люди < -> Квартиры - создать пакет tenants, который будет работать с моделями & услугами людей & квартиры.

источник

2016-09-15 08:58:20

Спасибо за ваш ответ! Да, вопрос может быть слишком общим. Я просто думаю, что разделение моделей на отдельный пакет не похоже на DDD-путь ... Я уже использовал композицию, но это не помогло с избыточным кодом: модель Person должна быть как в квартирах, так и в квартирах. Разделение Арендаторов на другой пакет - отличное решение, попробует его наверняка, он может добавить дополнительные поля к Лицу (например, «его квартиру»), делая его Арендатором, но не может сделать то же самое для квартиры (например, «своих арендаторов» '), потому что для операций с квартирами мы используем пакет апартаментов. –

Вы не можете иметь независимость и двунаправленную осведомленность. Возможно, нет необходимости в квартире, чтобы знать что-либо о арендаторах, а просто список идентификаторов. Затем вы можете сделать что-то «tenants.GetByIDs (apartment.CurrentTenantIDs)». Перспектива ответа так же хороша, как «спасибо»;) –

Golang DDD реализация зависимых модулей

ответ

Смежные вопросы