BeanFactory and ApplicationContext: Spring's Two Container Interfaces

Spring's container is described by two Java interfaces. BeanFactory is the root one: it creates beans, wires their dependencies, and hands them out on request. ApplicationContext extends it and adds what a real application needs on top, and it is the one your code uses.

Calling context.getBean(...) on a context started with AnnotationConfigApplicationContext is calling it on an ApplicationContext. You will type ApplicationContext far more often than BeanFactory, because Spring Boot gives you one directly and nothing asks you to reach past it.

The relationship is ordinary Java inheritance: an ApplicationContext is a BeanFactory, so every method of the smaller interface is available on the larger one. What it adds is the machinery around bean creation. It creates singleton beans (the default kind, of which Spring makes exactly one) as soon as it starts, it publishes application events (messages one part of an application sends to the others), it looks up translated messages, and it registers the processors that make annotations such as @PostConstruct (run this method once the bean is set up) and @Autowired (inject a dependency here) work.

DefaultListableBeanFactory is the plain factory on its own: it can create beans, but it does not even process @PostConstruct unless you register that support yourself. AnnotationConfigApplicationContext wraps a factory like that and adds everything else, which is why it is the one you start in practice.

So when documentation says "the container", it almost always means an ApplicationContext. BeanFactory matters when you read Spring's reference documentation or its source, where it names the core of the container.