Cohesion и Coupling: отличия

[indestructable]

Поскольку Order и Product могут быть разными агрегатами или даже находится в разных сервисах (микросервисах, если проект достаточно большой), то во время добавления OrderLine (метод AddLine) лучше не передавать объект product, а использовать его id.

Зависит от того, что лежит в классе Продукт. Например, если при заказе используются только те данные, которые уже есть в продукте (например, все цены лежат в нем), то лучше передать продукт целиком, чтобы не создавать лишнюю зависимость на репозиторий или сервис продукта.

[ArkadiyXIII]

Тут больше зависит от того, как взаимодействуют между собой 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).

[Flammar]

Мне одному показалось, что случаи идеального кода и плохих границ проиллюстрированы одной и той же картинкой?

[thank_accept]

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели". И соответственно идеальных вариантов coupling\cohesion может быть масса, у каждого что-то свое.

И строить приложение от архитектуры - такое себе.

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

Самая лучшая архитектура как по мне это когда ты пишешь в ООП стиле, и вот тут как ты умеешь моделировать что-то, такая архитектура у тебя и получится, со всей связностью и связанностью.

Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.

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

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.