TS не является ОО или не ОО. Вы можете использовать его в методах модели предметной области, сервисных методах или высокоуровневых методах приложений. Это просто означает, что вы можете прочитать бизнес-намерение программы, не прокручивая миллион обратных вызовов и «черную магию».
Вот почему Microsoft представила async/await. Он превращает неясно выглядящий стиль отправки обратного вызова (делегата) и выхода, обработки обратного вызова в отдельном методе (обязательно) в удобочитаемый сценарий транзакции.
GOTO плохи, потому что они нарушают удобочитаемый поток сценария транзакции, делая его плохим.
а) Неправильный сценарий транзакции — это антипаттерн. Например, один огромный метод, отсутствие или несколько вызовов метода и т. д. Разные уровни операций в одном и том же методе (рефакторинг их в методы). Отдельные шаги бизнес-процесса вместе в одном методе (разбейте их на методы или отдельные классы. Много бизнес-объектов? Используйте сервисный шаблон DDD).
б) НЕправильное использование TS является антипаттерном. Например, тонны обмена сообщениями между приложениями, запуск событий и т. д., поэтому вы не можете прочитать и увидеть бизнес-процесс (функциональное требование для технических приложений). Детали низкого уровня (технические) смешаны с функциональной работой. Чрезмерное разделение деятельности, которая должна быть видна на одной странице.
Использование TS должно быть фрактальным, с каждым увеличением детализировать логику стиля TS. Высокий уровень: вы видите вызовы методов и использование службы DDD. средний уровень может быть чем-то вроде микса. Ниже находятся в основном вызовы методов/свойств объекта предметной области, а также мельчайшие детали логики.
Бросать TS под автобус, потому что им можно злоупотреблять, или предотвращать его использование, просто пинать банку в сторону - разработчик, который не может группировать и разделять и не знает SRP (единая ответственность) / Cohesion, испортит другие стили. , слишком. Ответ заключается в том, чтобы обучить их бизнес-процессу и привести примеры группировки и разделения, которые должны выполняться в соответствии с бизнес-/функциональными требованиями (вертикальный срез), а не с технологией (горизонтальный срез).
- поместите логику, которая имеет дело только с одним объектом домена или другими экземплярами его типа в DO. Не ссылайтесь на другие типы объектов из объектов домена (person.orders) и не вставляйте что-либо в объект домена (другой DO или репозиторий и т. д.). Это просто нарушает SRP. [скрипты низкоуровневых транзакций в методах]
- Когда вам нужно что-то вроде person.orders или вы чувствуете, что вам нужно что-то внедрить, создайте службу DDD (не сериализованную, без постоянных свойств после каждого использования). Введите, например, человека и другие коллекции (репозиторий или IQueryable и т. д.). Делай работу там. [скрипты транзакций среднего уровня здесь]
- объединить операции над объектами домена и DDD svcs в категории «методы приложений» служб DDD.
- построить и вызвать те из самого высокого уровня программы
на каждом уровне это выглядит как сценарий TX, однако соблюдайте правила. Держите методы небольшими. Тогда ты сможешь это прочитать!
Примечание. В ссылке, приведенной в другом ответе, Фаулер рассказывает вам, как сделать сценарий транзакции правильным, а не неправильным:
https://www.informit.com/articles/article.aspx?p=1398617
Он также предполагает, что это не ОО. Я думаю, вы можете скрестить его с OO и использовать плюсы TS (читабельность и сотни плюсов), а также сотни плюсов OO. Другими словами, вы можете поместить элементы TS в модель предметной области и составить использование модели предметной области в TS более высокого уровня.
Также рассмотрите определение сценария транзакции как отдельной транзакции базы данных. Поскольку в вашей модели предметной области НЕ должны быть внедрены репозитории (внедрять объекты предметной области в репозитории), вы можете организовать ее таким образом, вызывая соответствующие репозитории для (де)сохранения на самом высоком уровне. Но если это не так, смысл в том, чтобы поток читаемого кода не был чрезмерно разделен.
Проблема с критикой TS заключается в том, что люди думают, что SRP — это все о SoC (разделение задач), и им никогда не нужно беспокоиться о сплоченности (держите одни и те же вещи вместе, что также подразумевает SoC, но требует организации). Таким образом, инженеры с благими намерениями просто разделяют вещи на миллион частей (потому что чем больше, тем лучше), и логику понять сложнее.
person
FastAl
schedule
07.10.2020
