Архитектура игры на Unity без Zenject. Часть 2

Я уже запутался в сущностях. Раз уж сервис-локатор всё-равно используется, то MoveController проще выглядит c таким методом.

public void Construct(GameLocator gameLocator)
{
	this.input = gameLocator.GetService<IMoveInput>();
	this.player = gameLocator.GetService<IPlayer>();
}

Так можно избавиться от GameAssembler, который будет только бухнуть со временем (или их будет много разных?).

Да и сервис-локатор можно взять статический https://github.com/Leopotam/globals/blob/master/src/Service.cs , убрав GameLocatorInstaller. Всё-таки сервисы, которые юзаются через сервис-локатор, обычно знают, что они единичные, и регистрировать самим себя - нагляднее при чтении их кода.

Но это всё актуально, только если идти честным путём сервис-локатора, а не как промежуточный этап к самописному DI :)

Получается какая-то мешанина из ответственностей. И игрок, и клавиатура, и контроллер движения теперь вообще сервисы. Получается "прокинь что хочешь куда хочешь и будь что будет". А сервис локатор только упрощает такое поведение.
Почему бы тогда не прокинуть контроллер в игрока или ввод в игрока или игрока сразу в ввод? Раз уж они все сервисы.
Весь контроль управления зиждется на том, что мы постараемся не забыть что в проекте главнее)

От ассемблера пока не рекомендую избавляться, потому что в третьей части (спойлер) мы объединим классы GameObservableInstaller, GameLocatorInstaller и GameAssembler в один монобех-инсталлер, который будет заниматься созданием экземпляров с бизнес-логикой, регистрацией сервисов и лисенеров + прокидыванием в них зависимостей. 

Вот тут лично мне кажется, что принцип единственной ответственности будет сильно нарушаться - слишком много причин для изменений получается (если следовать определению единственной ответственности, предложенному господином Мартином), поправьте меня, если я ошибаюсь. Почему нельзя оставить так как есть?

Вы в целом правильно описали проблему, которая приписывается сервис локатору.
Но получается забавно - пытаясь избавиться от DI, вы переизобрели DI
По сути если унифицировать класс assembler - это и будет DI
Например можно сделать его универсальным через рефлексию или рефлексию + кодогенерацию, чтобы не писать много однотипного кода.

Еще комментарии:
- Сервис локатор можно сделать ScriptableObject со списком префабов-сервисов, которые он инициализирует лениво при запросе. Так его будет проще внедрять.
- В юнити в принципе можно использоват ScriptableObject + сериализацию (SerializeField) как встроенный DI. Хорошо работает для общих сервисов, настроек вьюшек и многих других целей
- Можно оптимизировать локатор (впрочем не уверен, для маленького списка сервисов список должен быть быстрее, нужно тестировать)

public sealed class ServiceLocator {

  private readonly Dictionary<Type, object> services = new Dictionary<Type, object>();
  public void AddService(object service)
  {
      this.services.Add(service.GetType(), service);
  }
  
  public void RemoveService(object service)
  {
      this.services.Remove(service.GetType());
  }
  
  public T GetService<T>()
  {
      if (services.TryGetValue(typeof(T), out var service)) {
          return (T)service;
      }
  
      throw new Exception($"Service of type {typeof(T)} is not found!");
  }
}

- Так же можно обобщить его через Generic интерфейсы - сделать специальный интерфейс Construct<T> и проверять из ассемблера, поддерживает ли класс один из списка.
И прописать списочком зависимости (в этом случае нужно будет писать множество конструкторов для каждого типа данных, по сути это скорее внедрение через поля) либо множественный Construct<A, B>, Construct<A, B, C>, Construct<A, B, C, D> (в этом случае можно будет написать нормальные конструкторы вплоть до 5 параметров, но чтобы нормально их внедрить, все равно нужна рефлексия, чтобы найти в проекте все классы, которые поддерживают варианты конструкторов и использовать только нужные из списка, потому что все варианты проверить нереально)
Правда статическую компиляцию всего этого добра обеспечить довольно трудно, но можно попытаться через лямбды.

А можно не заниматься ерундной, взять готовый контейнер и на этом успокоиться. Долго сам использовал сервис-локатор самописный, пока не взял Zenject. После этого понял, что пока у вас нет конкретной причины отказаться от готового DI-Container'a, делать этого не надо.