I think that AccountType is another aggregate root which is referenced from the Person aggregate root.
It's absolutely normal to have many simple aggregate roots, see Vaughn Vernon articles, see part 1, p. 5:
On one project for the financial derivatives sector using
[Qi4j], Niclas [Hedhman] reported that his team was able to
design approximately 70% of all aggregates with just a
root entity containing some value-typed properties. The remaining 30% had just two to three total entities. This doesn't indicate that all domain models will have a 70/30 split. It
does indicate that a high percentage of aggregates can be
limited to a single entity, the root.
In your question it's not quite understood, what is the problem with accessing repositories to initialize the aggregate root's properties:
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
The initialization of the Person class should be handled by PersonFactory.
The PersonFactory is a service, so it can have reference to AccountTypeRepository to find a suitable AccountType instance and return a fully constructed Person instance of that type.
update: Also I'd like to add a note that referencing your AccountType by id works equally well. It's all matter of convenience, sometimes it's more convenient(only for displaying, not for modifying, of course) to access the references directly if you use GUI frameworks with rich data binding capabilities like WPF or Spring MVC so you can directly access this properties to display in View. If you are using the id approach, this may force you to create ViewModels (FormBeans) even for the simple Entities.
Regarding the
lookup-based solution, it works well for very simple enum-like fields, I suppose that
AccountType is something more complex than that and belongs to the knowledge level (see the discussion of the question).
Returning to the choice between aggregates and value object(also see this), it depends on the abstraction level and configuration capabilities of your information system.
From the point of view of the Account class it may look like a value object, you can replace one AccountType with another: it will be just like switching between Color value objects, but from the point of the knowledge level your user may want to customize the behavior of the system for selected AccountType, for example change discounts for specific "Premium" accounts. So if you have the knowledge level, AccountType will be something with an identity which leads you to creating a separate repository.
