We are currently having an internal debate on how our business logic classes should be structured. At the moment we structure our business classes like this:public class OrderBL{    public void CreateOrder(OrderDTO order)    {        //save order        //send email    }    public void CancelOrder(OrderDTO order)    {        //save order        //send email    }    public void MarkOrderAsDispatched(OrderDTO order)    {        //save order        //send email    }    //other private methods too}Using our current method above we find classes grow very quickly and can become confusing on big projects.There is some debate as to whether we should change our business classes to look like the below:public class CreateOrderBL{    public void RunLogic(OrderDTO order)    {        CreateOrder();        SendEmail();    }    private voide CreateOrder()    {    }    private void SendEmail()    {    }}The benefit to having this is that classes are easier to understand and are small, however the downside is that the number of classes increase.What is the correcty way to approach this? 
What should be in my business logic class
java;c#;design patterns;business logic
The correct way is the one that most effectively satisfies your application's non-functional requirements for maintainability, performance, etc.What you need is a Business Logic Layer or Service Layer.  These layers translates CRUD methods into actual business operations.  Yes, you'll have more classes, but those classes are going to be better organized and have better Separation of Concerns. I would avoid the wholesale use of Execute() style methods. Group your classes into business aggregates such as OrderProcessing or Shipping, and give your methods meaningful names such as ProcessOrder() (which calls CreateOrder and SendEmail).