2

The way I explain it to myself is that a business rule is a requirement for a domain concept of an application.

One of the core tasks of my current app is to send notifications. Therefore I have a Notification entity, amongst others.

We are now facing the situation that I need to split a message in 2 parts and batch send them, because the API service provider has a message length limit.

From my point of view, this could be seen as a business rule (the requirement comes directly from the app owner), application logic (message is too long to send in one go with the current API implementation), or even a concern of the presentation layer (email bodies are created from templates).

How can I identify which layer a rule like this would belong to?

Improve this question
5
  • You are asking three different questions. Could you please narrow it to one? I can tell you that having to batch messages is certainly not a business rule; it's simply an implementation detail in the application that SendNotification() should abstract for you.
    – Dan Wilson
    Commented Sep 25, 2018 at 13:15
  • That's the part that is unclear to me. A username not being allowed more than 20 characters is a business rule, an email body not allowed more than 500 chars is an implementation detail in my service.
    – Hans
    Commented Sep 25, 2018 at 13:19
  • 3
    I think you can usually figure it out by asking, "who created this requirement?" I could see a username length constraint coming from a business analyst, while an e-mail body length constraint comes from your service provider.
    – Dan Wilson
    Commented Sep 25, 2018 at 13:38
  • What differentiates an application logic from a business logic is necessity. Are you adding this because it is something which may vary and the program must work accordingly, or is it a technical necessity in order to work properly? In the latter case, it can still be configurable, but with little likelihood of changing, unlike the business logic.
    – Neil
    Commented Sep 25, 2018 at 14:12
  • This is an implementation workaround, not a business requirement. The business wants to send the message, in the cheapest, most efficient way. The service provider is actually placing a hurdle.
    – S.D.
    Commented Sep 26, 2018 at 5:51

3 Answers 3

Reset to default
7

A business rule is defined by business people and relates to business matters, regardless of the way these rules are implemented.

Unambiguous examples:

  • The change of the bank account of a beneficiary has to be approved by a different accountant than the one who registered the change (four eyes principle).
  • A purchase agent can issue a purchase order up to $100K. Above this ceiling an approval by a manager is required.

These rules may be enforced purely with organisational means (a formal procedure that the employees gave to follow) or through automation (in the system).

Ambiguous example:

  • The title of the report shall be less than 140 characters
  • The product description shall be no longer than 2000 characters

These two examples could be:

  • technical specifications of an arbitrary length, not justified by a business rule, but just because it is assumed to be sufficient;
  • true business rules, if the business people decided that the information should not exceed these limits under any circumstances due to business reasons, for example in order to ensure concise answers and efficient processing (and avoid that the clerks have to read long novels instead of short statements).

To determine if it's a business rule, the easiest criteria would be to ask if this rule would make sense without the system (for example, if the information would be processes via paper forms). In your example it clearly isn't.

A business rule is in general implemented in the business logic layer, because of its general nature (independent of the application).

Improve this answer
6
  • How would this apply to the username length example? The username wouldn't even exist w/o the system.
    – Hans
    Commented Sep 25, 2018 at 14:40
  • 1
    I wonder if any non-IT manager would define a username length. What could be the business justification behind such a rule ? I think there might be a confusion between "specification endorsed by business" and "business rule"
    – Christophe
    Commented Sep 25, 2018 at 14:57
  • I had a requirement in an earlier version of the app for a username to only consist of integers, because they wanted to map it to a phone number. So maybe that wasn't a business rule after all, but just something to use for input validation.
    – Hans
    Commented Sep 25, 2018 at 15:58
  • @Michael Interesting! The specification (length and only digits) is derived from the business rule (account number is phone number) that could have a business justification (e.g. need to validate identity with callback ? service associated with a phone subscription,...). I'd expect in this case the business analyst to clarify if this rule is really about the identification of the account (and what happens if user changes phone number), or if the rule is about the validation of an account with a phone call/call id/sms and one could imagine to have another account identifier.
    – Christophe
    Commented Sep 25, 2018 at 16:45
  • @Michael In this case, I'd expect this to be in the business logic, because it's about the validity of domain object regardless of the functionality and feature offered by the application.
    – Christophe
    Commented Sep 25, 2018 at 16:47
3

There's plenty of gray area and overlap between business rules and application logic, but to be a business rule, a requirement should be a requirement which creates value for the business.

Given the example of sending a message and having to split it in two because of the API, the true business requirement is probably that the app has to be able to send a message of arbitrary length. The app owner would potentially loose money if users were unable to send longer messages. Splitting the message into multiple parts would be the implementation of that business rule.

Improve this answer
2
  • I was thinking something similar, but then I didn't see where ie. a username length would create business value.
    – Hans
    Commented Sep 25, 2018 at 13:58
  • 1
    For the username, it really depends on why. For example, if an existing system only allows specific lengths of username, the business requirement is really to be able to integrate with the existing system, which comes with technical requirements about username length. If the requirement was because having short, memorable usernames would increase app engagement or something like that, then it's arguably a real business rule.
    – Eric Damtoft
    Commented Sep 25, 2018 at 15:22
1

That would not be a bussiness rule.

Business rules should be collected, and ideally be referred to in the source code.

They should describe the logic with respect to all business aspects: after printing an invoice, the invoice number cannot be changed anymore, and has to be put in the audit log.

Now one can have a business rule: send a notification on this ... event. The implementing code may refer to this business rule, and state that if needed it splits a too large message in two parts separately sent. That does not look like a requirement on beforehand, but an implementation documentation afterwards. A bit like "one can click on the i to receive contextual online-help."

If one only has business rules, fine, add the implementation details. Otherwise keep them separate, keep the business rules' ownership neutral and without too much fluff: the business people should not feel overrestricted by imposed details/"corrections." It is like pagination of lists and such. "The results must come in limited pages, though an entire scrollable list must be selectable too." That is - as you said - something for application design. And - in contrast to decisive business rules - tells something on the interna.

Having two messages must be explained. But let me give a comparison:

An architect tells: for a building for N people and M floors there are K lifts. The building owner will want to have the technical documentations: how the elevators intelligent wait on first and top floor, what strategy to respond to a button press and such. Important technical implementation details, intelligent design decisions. Sending two notification messages falls in the same category.

In the business rule "notification message" needs to be changed in "notification as one or two messages (foot note: if the notification becomes too long)" but technical justification and details should go elsewhere.

Now the implementation may be changed without the business rules being effected much (those rules will deal with a "notification", not a single partial "message").

Improve this answer
4
  • Does this mean I would, from your point of view, need a business rule like message in one or two parts and a technical implementation in my service layer?
    – Hans
    Commented Sep 25, 2018 at 14:08
  • 1
    Yes, that is: not overspecifying in the business docs, one might even tell the reason for more than one part - as an aside, non-prescriptive.
    – Joop Eggen
    Commented Sep 25, 2018 at 14:16
  • In your metaphor with the building, where would business logic fit in? How do you distinguish "business logic" from say, technical specifications of the building? I think you're on the track, but you lost me somewhat. Could you clarify?
    – Neil
    Commented Sep 25, 2018 at 14:20
  • The business logic would give an approximate number of elevators based on the number of peoples and floors (maybe based on some sensible data). The implementation could become mathematical, involve fluid dynamics and intelligent deployment strategies for the lifts. A visitor is interested in having sufficient lifts. An owner has that as business logic & requirement. And an owner wants from the architect some more technical info. Metaphorically the architect would say here: you need two lifts instead of one.
    – Joop Eggen
    Commented Sep 25, 2018 at 14:28

Not the answer you're looking for? Browse other questions tagged or ask your own question.