Я за вариант 4. Самый удобный и читаемый, но я обычно сервисы не держу в доменном слое, все сервисы для бизнес логики - в бизнес слое (Application).
Может я в чем-то ошибаюсь, будет интересно почитать другие мнения, почему сервис проверки уникальности почты/репозитории/др. должны находиться в Domain слое, а не в Application.
Чтобы оставались комментарии к методам/свойствам/etc., нужно генерировать документацию, которая должна будет попасть в nuget пакет, включать так (в настройках проекта):
Либо в .csproj файле в блоке <PropertyGroup> добавить
Можно сделать API общий для всех ваших проектов, который будет принимать пуши от платежки и раскидывать уведомления дальше (HTTP REST, RMQ, etc.), никаких проблем, вроде, это не должно составить
Работаю с ГИС ЖКХ через их "Веб-сервис", это сущий ад, кошмар и ужас, сервис полностью асинхронный, нельзя в моменте получить данные как с другого нормального апи, нужно ждать время, делать перезапросы, всё это подписывать и в XML (о ужас) отправлять, поэтому я тоже думаю, что будет кошмар :)
using (var client = new SmtpClient()), а потом client.Dispose();, а зачем Dispose?
Давно уже существует конструкция using var, имхо, но для глаза приятнее
Какие-то магические Bcc и Cc в конструкторе, что они означают? (если комментарии в полном коде у конструктора есть, то вопрос отпадает)
Не придирка, а просто вопросы:
не пробовали все файлы настроек складывать в отдельную папку? Имхо, но мне показалось это в разы удобнее, чем когда они находятся в корне.
не пробовали разделение настроек, чтобы не все в appsettings.json складывать? я обычно такие вещи разбиваю на логические куски, например: SerilogSettings.json (настройки для Serilog'a), MongoSettings.json (настройки для MongoDB), etc. В вашем примере хорошо (ИМХО!!!) подошло разделение конфига: appsettings.json, mailsettings.json
Меня автоматически браковали из-за отсутствия вышки (которой, к слову, до сих пор и нет). Но меня дико раздражает, что берут часто глупых, но с вышкой. На собеседования даже не зовут, когда видят "нет высшего", сразу отказ даже в разговоре с HR. Они даже не интересуются, что ты умеешь и что знаешь, а я хочу развиваться, писать красивый и лаконичный код, заниматься архитектурой приложений, но закрывают двери из-за вышки, после которой люди даже не поймут и 10% моего кода, который я на данный момент пишу (в данный момент работаю, 1 компания в меня поверила и взяла без "вышки").
HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"? Меня научат в универе разрабатывать микросервисы, расскажут зачем нужен EntityFramework, DTO модели, AutoMapper и прочие вещи? Очень сомневаюсь.
А мы решили оставить на net framework grpc сервис, который только принимает в себя сырой XML и отдает обратно подписанный, который и отправляется дальше, доставило в разы меньше боли :)
Почему
Stopwatch, когда есть BenchmarkDotNet?Я за вариант 4. Самый удобный и читаемый, но я обычно сервисы не держу в доменном слое, все сервисы для бизнес логики - в бизнес слое (Application).
Может я в чем-то ошибаюсь, будет интересно почитать другие мнения, почему сервис проверки уникальности почты/репозитории/др. должны находиться в Domain слое, а не в Application.
Чтобы оставались комментарии к методам/свойствам/etc., нужно генерировать документацию, которая должна будет попасть в nuget пакет, включать так (в настройках проекта):
Либо в .csproj файле в блоке <PropertyGroup> добавить
Если бы да кабы :)
Спорить можно вечно
Я так думаю, что в нормальных командах можно сразу обговорить эти детали, чтобы потом не возникало проблем
Можно сделать API общий для всех ваших проектов, который будет принимать пуши от платежки и раскидывать уведомления дальше (HTTP REST, RMQ, etc.), никаких проблем, вроде, это не должно составить
Работаю с ГИС ЖКХ через их "Веб-сервис", это сущий ад, кошмар и ужас, сервис полностью асинхронный, нельзя в моменте получить данные как с другого нормального апи, нужно ждать время, делать перезапросы, всё это подписывать и в XML (о ужас) отправлять, поэтому я тоже думаю, что будет кошмар :)
Почему проект называется в lowerCamelCase?
using (var client = new SmtpClient()), а потомclient.Dispose();, а зачем Dispose?Давно уже существует конструкция
using var, имхо, но для глаза приятнееКакие-то магические Bcc и Cc в конструкторе, что они означают? (если комментарии в полном коде у конструктора есть, то вопрос отпадает)
Не придирка, а просто вопросы:
не пробовали все файлы настроек складывать в отдельную папку? Имхо, но мне показалось это в разы удобнее, чем когда они находятся в корне.
не пробовали разделение настроек, чтобы не все в appsettings.json складывать? я обычно такие вещи разбиваю на логические куски, например: SerilogSettings.json (настройки для Serilog'a), MongoSettings.json (настройки для MongoDB), etc. В вашем примере хорошо (ИМХО!!!) подошло разделение конфига: appsettings.json, mailsettings.json
У меня рекорд был около 200 откликов, надо ли говорить сколько было приглашений на собеседование?)
Потому что сначала смотрят на опыт в резюме, а потом на собеседовании уже смотрят на умения :)
Язык как и в посте - C#. Надеюсь, что позже будут приглашать уже из-за опыта, а не из-за того, что у меня, например, есть вышка, а у другого её нет.
Это было и до, и после
Не очень хочется тратить время и деньги на получения абсолютно не нужных знаний, которые забирают только время :(
Меня автоматически браковали из-за отсутствия вышки (которой, к слову, до сих пор и нет). Но меня дико раздражает, что берут часто глупых, но с вышкой. На собеседования даже не зовут, когда видят "нет высшего", сразу отказ даже в разговоре с HR. Они даже не интересуются, что ты умеешь и что знаешь, а я хочу развиваться, писать красивый и лаконичный код, заниматься архитектурой приложений, но закрывают двери из-за вышки, после которой люди даже не поймут и 10% моего кода, который я на данный момент пишу (в данный момент работаю, 1 компания в меня поверила и взяла без "вышки").
HR, вопросы к вам, как моя ценность, как сотрудника, вырастет, если я получу "вышку"? Меня научат в универе разрабатывать микросервисы, расскажут зачем нужен EntityFramework, DTO модели, AutoMapper и прочие вещи? Очень сомневаюсь.
Накипело, извините :(
Я, я был в такой ситуации! Когда мной пытались открыто манипулировать, но увы и ах :)
А мы решили оставить на net framework grpc сервис, который только принимает в себя сырой XML и отдает обратно подписанный, который и отправляется дальше, доставило в разы меньше боли :)