It had been really vague to me about what exactly is business logics for a long time. But now I understand what it is, it helps me how I organize my code. The definition may vary to the people, but I have one solid definition which I have been able to rely on.
The conclusion first. Business logics are the logics that satisfy your business requirements. Pretty natural, but still vague, right? Let me give you an example. If your system needs to upload a file to S3 and if successful, send an email to administrators.’ The first point I need to give you is, as you might have guessed, business logics are procedural (for most cases). That’s it about business logics? Actually, yes.
But another concept I wanted to introduce to you was “domain logics”. Let’s define it here as “The logics that are dedicated to a domain.” In this case, uploading the file to S3 is one domain. Probably you want to record the process into your database which is another domain. And sending an email is another domain, too. (Actually there are logics that face the user but for simplicity we don’t think about it here. Also, you could upload file to s3 directly from client, but for the sake of explanation, let’s make the file go through our own server to s3.)
Why did I want to introduce domain logics? Because you can always decompose your business logic into domain logic(s). Sometimes business logic is equal to one domain logic. And if this is MVC, how would you organize your code? This conclusion might be something you have guessed already. Models are where your domain logics reside. They should be free from procedural concept. They should not know other doamins, need to be loose-coupled from each other. Their methods should be reusable and stable. (My motto is always be loose-coupled.) Now you can have single responsible domain models. Now you know domain logics are a part of business logics. Then where should other business logics go? Well, that takes me another blog post :) I hope I can write it someday but before that, MVC + Layered Architecture (Rails) hopefully helps you.
By the way, for Rails, as one of the beginners’ mistake is they think models need to be Active Records. That’s untrue. Consider why ActiveModel is separatly available from Active Records.
This time I just wanted to let you know the concept of domain logics. You should always think about it when you think about your business logics.