Здравствуйте, Nikita Lyapin, Вы писали:

NL>Привет всем!

NL>Часто возникают обсуждения о том где размещать бизнес-логику приложения. В итоге я собрался силами, систематизировал свои знания по этому вопрос и написал статью. Здесь
NL>По большому счету Фаулер все написал, но я взял на себя смелость его дополнить. Я прав? Или ошибаюсь? Хотелось бы обсудить с сообществом.

Я тепрь тоже подавлю авторитетом, предложив прочитать серию статей Эрика Липперта (небезызвестный человек) про моделирование предмтной области с помощью классов и методов

https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/
https://ericlippert.com/2015/04/30/wizards-and-warriors-part-two/
https://ericlippert.com/2015/05/04/wizards-and-warriors-part-three/
https://ericlippert.com/2015/05/07/wizards-and-warriors-part-four/
https://ericlippert.com/2015/05/11/wizards-and-warriors-part-five/

Они изначально берет задачу моедлирования, когда нет внешних хранилищ, пользовательных запросов и затрат на вытагивание данных.
Казалось бы идеальная ситуация для "domain model"

Небольшим усложнением "бизнес-правил" он добивается того, что наивный ООП-код на C# перестает описывать павила достаточно внятно без лишнего количества технических деталей.

В итоге приходит к выводу, который я процитирю:

The fundamental problem is my initial assumption that the business rules of the system are to be expressed by writing code inside methods associated with classes in the business domain

Чтобы согласиться с ним надо обязательно прочитать все пять статей, чтобы понять то, о чем он говорит.

Далее липперт выводит то, что называется anemic model

Now all our previous problems fade away. A player has a weapon, great, that’s fine, we’ll make a Player class with a property of type Weapon. That code makes no attempt to try to represent that a wizard can only wield a staff or a dagger; all that code does is keep track of game state, because state is its concern.

Далее он описывает архитектуру, которую фаулер назвал бы transaction script

Then we make a Command object called Wield that takes two game state objects, a Player and a Weapon. When the user issues a command to the system “this wizard should wield that sword”, then that command is evaluated in the context of a set of Rules, which produces a sequence of Effects.

Бизнес-правила он предлагает описывать классам-стратегиями (так же, как показывал Синклер).

Всем рекомендую почитать эту серию статей для очистки мозга.

Здравствуйте, Nikita Lyapin, Вы писали:

NL>Привет всем!

NL>Часто возникают обсуждения о том где размещать бизнес-логику приложения. В итоге я собрался силами, систематизировал свои знания по этому вопрос и написал статью. Здесь
NL>По большому счету Фаулер все написал, но я взял на себя смелость его дополнить. Я прав? Или ошибаюсь? Хотелось бы обсудить с сообществом.

Я тепрь тоже подавлю авторитетом, предложив прочитать серию статей Эрика Липперта (небезызвестный человек) про моделирование предмтной области с помощью классов и методов

https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/
https://ericlippert.com/2015/04/30/wizards-and-warriors-part-two/
https://ericlippert.com/2015/05/04/wizards-and-warriors-part-three/
https://ericlippert.com/2015/05/07/wizards-and-warriors-part-four/
https://ericlippert.com/2015/05/11/wizards-and-warriors-part-five/

Они изначально берет задачу моедлирования, когда нет внешних хранилищ, пользовательных запросов и затрат на вытагивание данных.
Казалось бы идеальная ситуация для "domain model"

Небольшим усложнением "бизнес-правил" он добивается того, что наивный ООП-код на C# перестает описывать павила достаточно внятно без лишнего количества технических деталей.

В итоге приходит к выводу, который я процитирю:

The fundamental problem is my initial assumption that the business rules of the system are to be expressed by writing code inside methods associated with classes in the business domain

Чтобы согласиться с ним надо обязательно прочитать все пять статей, и понять то, о чем он говорит.

Далее липперт выводит то, что называется anemic model

Now all our previous problems fade away. A player has a weapon, great, that’s fine, we’ll make a Player class with a property of type Weapon. That code makes no attempt to try to represent that a wizard can only wield a staff or a dagger; all that code does is keep track of game state, because state is its concern.

Далее он описывает архитектуру, которую фаулер назвал бы transaction script

Then we make a Command object called Wield that takes two game state objects, a Player and a Weapon. When the user issues a command to the system “this wizard should wield that sword”, then that command is evaluated in the context of a set of Rules, which produces a sequence of Effects.

Бизнес-правила он предлагает описывать классам-стратегиями (так же, как показывал Синклер).

Всем рекомендую почитать эту серию статей для очистки мозга.