с соответсвующей структурой и при этом нужно эти данные потом переводить в более удобные объекты предметной области. Что надо делать чтоб избавиться от следов БД?
Если приходится много маппить, не 5-10 полей, а переходит в 10-50, то стоит задаться вопросом зачем так много нужно данных для того чтобы сделать какое-то атомарное действие с сущностью.
Комплаенс, например. Ограничения прав. Я вот связываю внешнего клиента с внутренней системой. И ему не положено видеть половину данных, а другую половину должен видеть только в заданной форме.
Зачем внутренняя система отдает столько лишних данных, если клиенту нужна своя вьюха? Похоже на попытку 2-х разных кейсов реализовать через один метод API и потом подгоднять чтобы этот один удовлетворял 2-м разным сценариям вместо того чтобы сделать 2 разных метода API.
Это прямо так важно «зачем»?
Я к тому, что в некоторых случаях искать решение нужно за рамками текущего контекста. Можно обнаружить, что введены ненужные абстракции и точки соприкосновения.
Ну примерно так же как как чего делать
Какие же вы душные, пиздец. Давай объясню, чтобы вы не думали, что это велосипед, который придумывает масленок. У нас есть кор система. Там есть один еедроинт, который предназначен для внутренних целей. Эту систему пишет подрядчик. Продуктовой команде надо от кор системы получить часть данных. Эту часть данных можно получить только из кор системы. Но согласовать еедпоинт на кор системе - это пиздец. Административно невозможно. Поэтому на всех уровнях бюрократии решили поставить прослойку, которая сделает фильтрацию данных и конвертацию, которая уйдет клиентам. Надеюсь не будет вопросов «а действительно административно сложно пробить?», «а вам действительно нужен этот сервис?» и то.
Обсуждают сегодня