Комментарии 3
Поскольку Order и Product могут быть разными агрегатами или даже находится в разных сервисах (микросервисах, если проект достаточно большой), то во время добавления OrderLine (метод AddLine) лучше не передавать объект product, а использовать его id.
Зависит от того, что лежит в классе Продукт. Например, если при заказе используются только те данные, которые уже есть в продукте (например, все цены лежат в нем), то лучше передать продукт целиком, чтобы не создавать лишнюю зависимость на репозиторий или сервис продукта.
Тут больше зависит от того, как взаимодействуют между собой Order и Product. Как вы собираетесь передавать объект Product (я предполагаю, что вы имеете ввиду доменный объект, а не DTO), если Order и Product находятся в разных микросервисах. Даже если у нас модульный монолит. Order и Product скорее всего будут находятся в разных модулях. И если один будет напрямую зависит от другого, это как раз и есть нарушение low coupling. Тут или изначально работать с ID. Или внутри каждого модуля/микросервиса делать адаптеры (можно как угодно назвать, я имею ввиду, чтобы были некие сервисы, которые будут запрашивать данные у другого модуля/микросервиса и уже внутри модуля создавать объект Product, но это уже будет не доменный объект, а просто DTO). Такие адаптеры по сути можно назвать кстати anti-corruption layer (https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer).
Но нужно заметить, если проект достаточно простой, то можно не парится и так оставить. Но в тоже время в достаточно простых проектах можно забить и на эти принципи (high cohesion и low coupling).
Но нужно заметить, если проект достаточно простой, то можно не парится и так оставить. Но в тоже время в достаточно простых проектах можно забить и на эти принципи (high cohesion и low coupling).
Мне одному показалось, что случаи идеального кода и плохих границ проиллюстрированы одной и той же картинкой?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cohesion и Coupling: отличия