Сообщение Re[4]: DDD протаскивание других слоев через параметры методо от 23.11.2020 19:32
Изменено 24.11.2020 12:03 #John
Re[4]: DDD протаскивание других слоев через параметры методов Domain
Здравствуйте, Буравчик, Вы писали:
J>>Но и у него есть недостатки: бизнес логика дробится.
Б>И какая проблема из этого возникает (пример)?
Если тут использовать бизнес сервис, то придется часть метода(или весь метод) `UpdateStatus()` вынести в бизнес сервис,
там сделать проверку результата, а потом продолжить выполнение логики из метода "UpdateStatus".
Чем выше будет цикломатическая сложность/вложеных_методов тем сложнее/больше_кода придется вынести в бизнес сервис.
Б>Вообще, она всегда дробится. Вопрос лишь как — по сущностям или по сервисам.
Если выносить код в бизнес сервисы, то данные и способы их обработки оказываются разделены, что нарушает один из принципов ООП,
т.к. не позволяет модели обеспечивать собственные инварианты.
J>>Но и у него есть недостатки: бизнес логика дробится.
Б>И какая проблема из этого возникает (пример)?
class RootFoo
{
// ..
void DoSmth()
{
bar.DoBar();
// other logic ..
}
}
class Bar
{
// ..
void DoBar()
{
foo.UpdateStatus();
// other logic ..
}
}
class Foo
{
// ..
void UpdateStatus()
{
switch(..)
{
case "yyy":...;
case "xxx":
// Если не создавать бизнес сервис,
// бизнес-логика выглядит последовательной.
var x = new HttpClient().GetString("http://...");
if(x == "str")
{
// other logic ..
}
//..
}
// other logic ..
}
}
Если тут использовать бизнес сервис, то придется часть метода(или весь метод) `UpdateStatus()` вынести в бизнес сервис,
там сделать проверку результата, а потом продолжить выполнение логики из метода "UpdateStatus".
Чем выше будет цикломатическая сложность/вложеных_методов тем сложнее/больше_кода придется вынести в бизнес сервис.
Б>Вообще, она всегда дробится. Вопрос лишь как — по сущностям или по сервисам.
Если выносить код в бизнес сервисы, то данные и способы их обработки оказываются разделены, что нарушает один из принципов ООП,
т.к. не позволяет модели обеспечивать собственные инварианты.
Re[4]: DDD протаскивание других слоев через параметры методо
Здравствуйте, Буравчик, Вы писали:
J>>Но и у него есть недостатки: бизнес логика дробится.
Б>И какая проблема из этого возникает (пример)?
Если тут использовать бизнес сервис, то придется часть метода(или весь метод) `UpdateStatus()` вынести в бизнес сервис,
там сделать проверку результата, а потом продолжить выполнение логики из метода "UpdateStatus".
Чем выше будет цикломатическая сложность/вложеных_методов тем сложнее/больше_кода придется вынести в бизнес сервис.
Б>Вообще, она всегда дробится. Вопрос лишь как — по сущностям или по сервисам.
Если выносить код в бизнес сервисы, то данные и способы их обработки оказываются разделены, что нарушает один из принципов ООП,
т.к. не позволяет модели обеспечивать собственные инварианты.
J>>Но и у него есть недостатки: бизнес логика дробится.
Б>И какая проблема из этого возникает (пример)?
class Root
{
// ..
void Smth()
{
bar.DoBar();
// other logic ..
}
}
class Bar
{
// ..
void DoBar()
{
foo.UpdateStatus();
// other logic ..
}
}
class Foo
{
// ..
private StatusEnum status;
void UpdateStatus()
{
switch(..)
{
case "yyy":
status = StatusEnum.Old;
break;
case "xxx":
// Если не создавать бизнес сервис,
// бизнес-логика выглядит последовательной.
var x = new HttpClient().GetString("http://...");
if(x == "str")
{
status = StatusEnum.New;
// other logic ..
}
//..
}
// other logic ..
}
}
Если тут использовать бизнес сервис, то придется часть метода(или весь метод) `UpdateStatus()` вынести в бизнес сервис,
там сделать проверку результата, а потом продолжить выполнение логики из метода "UpdateStatus".
Чем выше будет цикломатическая сложность/вложеных_методов тем сложнее/больше_кода придется вынести в бизнес сервис.
Б>Вообще, она всегда дробится. Вопрос лишь как — по сущностям или по сервисам.
Если выносить код в бизнес сервисы, то данные и способы их обработки оказываются разделены, что нарушает один из принципов ООП,
т.к. не позволяет модели обеспечивать собственные инварианты.