Domain Driven Design: Value Objects и Entity Framework Core на практике

var firstName = new Name(model.FirstName);
var lastName = new Name(model.LastName);
person.PersonalName = new PersonalName(firstName, lastName);

1. Допустим, что имя не должно именяться, только фамилия
   
   Person.cs

   public class Person {
       
       ...
       
       public PersonalName PersonalName { get; private set; }
   
       public void UpdateLastName(Name lastName) {
           if (lastName == null) {
               throw new ArgumentNullException(nameof(lastName));
           }
   
           this.PersonalName = new PersonalName(
               this.PersonalName.FirstName, 
               lastName);
       }
   }

   возраст — вообще элементарно:
   

   person.Age = new Age(newAge);

2. Логика фильтрации — в репозитории. В статье есть пример — IPersons.GetOlderThan(Age age).
   Домен — это ядро всего приложения, все его возможности доступны всем слоям, которые с ним работают. Назовите хоть одну причину, почему подсистема А может иметь доступ к IPersons.GetOlderThan, а подсистема Б — не может. Это ведь одно приложение. Если уж совсем нужно — это можно сделать на уровне сборок, но никакого смысла я в этом не вижу.
   
3. Где каша? Почему мы не должны знать про Name и Age у Person? Это же публичный доменный объект.
   Если вы имели в виду преобразование Person -> PersonModel, то тут я согласен — обычно это делает отдельный PersonModelBuilder (сервис уровня Presentation layer). В статье я это опустил, потому что статья не про правильное программирование с DDD в целом, а конкретно про Value Objects.
   
4. Я это упоминал в материале. Мы не должны раскрывать детали реализации Persistence. Использование DbContext и DbSet очевидно нарушает это правило. Если проект не использует DDD — конечно же никакие репозитории и UoW не нужны.

void SomeMethod(string name, string phoneNumber);

void SomeMethod(Name name, PhoneNumber phoneNumber);

И насчет ValueObjects, я не знаю, откуда взято то, что они immutable.

Представьте, что в вашем домене 40 свойств. Вы не можете напрямую их изменять из ваших сервисов, а значит у вас будет еше 40 методов на изменение этих свойст. Получается, чтобы просто поменять 5 свойств из модели, мы должны сделать 5 вызовов.

А где тут написано, что нужен отдельный метод на изменение каждого свойства?

Касаемо логики фильтрации. Представьте, что у вас два десятка полей, по которым можно фильтровать. Скорее всего, вы захотите использовать какой-нибудь экспрешион, а не писать 20! методов. Сразу возникает вопрос, где будет происходить его формирование в случае DDD.

Так нужно же писать только те методы, которые будут позже использоваться, а не все возможные.

Права доступа. Пример. Админ может менять паспортные данные, клиент — нет. Желательно, чтобы этих методов команда разработки клиентов просто не видела.

Кажется, в DDD было что-то про фасады и контексты...

Да EntityFramework и скрывает от вас реализацию Persistence. Вы можете использовать кучу конкретных провайдеров, хоть в память, а хоть и свой для сохранения в файл напишите.

Вот только эти провайдеры должны уметь слишком многое, и в конечном счёте любой из них сводится к какой-то базе данных.

Чем более ограниченный интерфейс для слоя хранения используется — тем проще этот самый слой хранения писать.

Никогда. Нет, не так. НИКОГДА так не делайте для бизнес логики. Просто померяйте скорость обработки исключений. Вместо 20к запросов в секунду у вас будет 200.

Предполагается, что в рабочей программе эта проверка никогда не сработает. Исключение, которое никогда не возникает, ну никак не повлияет на производительность.