Qual seria a "melhor" maneira para organizar as classes em um projeto?

A lógica de adicionar/remover produtos do estoque deve estar na própria classe Estoque, mais ou menos assim:

class Estoque{
   private Produto [] produtos = new Produto[MAX_PRODUTOS];

   public void adicionaProduto(Produto p){ /* ... */ }
   public void removeProduto(Produto p){ /* ... */ }
}

Na sua classe Main você pode ter algo do tipo:

class Main{
   public static void main(String [] args){
        Estoque estoque = new Estoque();
         
        //lê as entradas ...
        if( opcao == 1){
           estoque.adicionaProduto(p);
        }else{
           estoque.removeProduto(p);  
        }     
   }
}

Não seria melhor ele criar uma classe controller e o controller ter os métodos de removerProduto e adicionarProduto?

Pois é. Acho que o Estoque assim como o Produto devem ser um simples POJO.
Pode-se criar uma classe que represente o serviço de manipulação desses POJO´s, no caso, seja para adicionar algo ao estoque, remover produto entre outros.

De maneira nenhuma! Adicionar/Remover produtos de estoque são regras de negócio, elas fazem parte do domínio da aplicação, portanto, eles devem ser colocadas na classe que representa essa entidade do domínio.

Controllers só fazem sentido quando se trabalha com MVC. No caso, o Controller serve para ligar as classe de negócio com uma View específica. Se você acoplar uma regra de negócio em um Controller é praticamente a mesma coisa que acoplar a regra de negócio à View.

Pois então, venho fazendo desta forma, colocando as regras de negócio, tais como os métodos adicionar e remover, dentro da classe da qual essas regras fazem parte, porém com uma ressalva, todas as entradas de dados são feitas feitas na classe principal.

Claro, pois assim você pode trocar o seu método de entrada (trocar de console para GUI por exemplo) sem alterar a sua classe de regra de negócios.

Eu, particularmente, entendo que uma classe chamada “Estoque” nada mais é que um POJO (entity, como eu uso JPA).
Ele nada tem além dos famosos getters e setters. Para tal, tenho um DAO e uma camada de serviço. O DAO só é acessado via camada de serviço e a camada de serviço ou é chamada de outra classe da mesma camada ou da camada de view, supondo JSF, seria o Managed Bean.

Acredito que fique mais claro e melhor separada as funções nesse formato, assim como sua organização.
Mas é uma opinião minha, obviamente.

nel:

Eu, particularmente, entendo que uma classe chamada “Estoque” nada mais é que um POJO (entity, como eu uso JPA).
Ele nada tem além dos famosos getters e setters. Para tal, tenho um DAO e uma camada de serviço. O DAO só é acessado via camada de serviço e a camada de serviço ou é chamada de outra classe da mesma camada ou da camada de view, supondo JSF, seria o Managed Bean.

Acredito que fique mais claro e melhor separada as funções nesse formato, assim como sua organização.
Mas é uma opinião minha, obviamente.

Eu também trabalho dessa forma. No caso a camada de serviço eu utilizo EJB

evertonsilvagomesjava:

nel:

Eu, particularmente, entendo que uma classe chamada “Estoque” nada mais é que um POJO (entity, como eu uso JPA).
Ele nada tem além dos famosos getters e setters. Para tal, tenho um DAO e uma camada de serviço. O DAO só é acessado via camada de serviço e a camada de serviço ou é chamada de outra classe da mesma camada ou da camada de view, supondo JSF, seria o Managed Bean.

Acredito que fique mais claro e melhor separada as funções nesse formato, assim como sua organização.
Mas é uma opinião minha, obviamente.

Eu também trabalho dessa forma. No caso a camada de serviço eu utilizo EJB

Me too. Já cogitei a possibilidade de utilizar o pattern Business Delegate, mas não foi necessário.