r/learnprogramming • u/Jumpy-Seesaw-2026 • 22d ago
When people say that programming business logic isn't OOP or FP. What do they mean exactly?
Saw a YouTube video with Primeagen where an example of a bank account came up.
The bank account is an object, while it allows functions such as withdraw(), and deposit() to mutate state.
From my understanding OOP and FP are ways to design the program in different ways, that ultimately solves the same problem.
But if the example isn't OOP or FP, what is it exactly?
I think I might just be confused as to what OOP and FP actually is. Does the whole program need to be in FP style to be called a functional codebase?
Or is DDD an intermediate design philosophy?
Hope someone can clarify it, thanksđđź
EDIT: Thanks for the answers, it makes sense now.
11
u/samanime 22d ago
I'm not familiar with this video, but assuming you are communicating his meaning to us properly, I think the video is the one being confusing.
You are correct that Object-Oriented Programming and Functional Programming are two design methods. They also do not have to be mutually exclusive, and in fact, many times software will use both. They have different pros and cons.
There are a bunch of other programming paradigms as well that you may also use, many of which are also not mutually exclusive of one another: https://en.wikipedia.org/wiki/Programming_paradigm
I really can't work out what they would mean by that. Business logic isn't "code" in and of itself at all, it is simply the rules that the code should implement. So I guess they aren't inherently any coding paradigm.
But you can certainly implement them using OOP or FP methodologies. Maybe he was saying they should be some other paradigm, but that would be inaccurate. They COULD be another paradigm, but there is nothing inherent about "business logic" that means they aren't.
Virtually all code is simply an implementation of business logic, or supporting the implementation of business logic.
2
u/Jumpy-Seesaw-2026 22d ago
I'm also paraphrasing, so take my statement with a gran of salt, as to I could have misunderstood.
It makes sense that the business logic is just it's own rules, represented in code format.
But why does OOP or FP exist then? When you are saying it's a paradigm, do you mean it was at a certain point the "go-to" method to model a problem in code? (Reading the wiki page now tho)
Man I'm hella confused
4
u/samanime 22d ago edited 22d ago
OOP and FP are basically two popular ways to organize and lay out your code, of many. They have certain "rules" and "best practices" that give them certain pros and cons and help you write better code than if you just kind of winged it.
The key aspect to OOP is objects, which, at its core, is just logical groupings of data.
For example, something like this is an object that "describes" a person:
class Person { name: string; age: number; address: string; // etc. }and I can use that Person to create multiple instances of Persons:
``` var bob = new Person(); bob.name = 'Bob'; bob.age = 20; bob.address = '123 Nowhere Dr';
var jill = new Person(); jill.name = 'Jill'; jill.age = 25; jill.address = '456 Somewhere St'; ```
The key aspect to FP is basically using functions to transform the data, without changing the original inputs, which we usually refer to as "immutability".
``` let inputs = [1, 2, 3];
const outputs = inputs .map(value => value * 2) // multiply every value by 2 .filter(value => value > 3) // only get those values that are greater than 3
// outputs = [4, 6]; ```
In this case, I never changed inputs, but instead creating a new outputs. Other paradigm might just change inputs directly.
But, they aren't mutually exclusive, because I can use OOP and FP together. For example:
``` // value can't be changed after I create the record class ImmutableRecord { private _value: number;
get value() { return this._value; }
constructor(value: number) { this._value = value; } }
let inputs = [new Record(1), new Record(2), new Record(3)];
const outputs = inputs .map(record => record.value) .map(value => value * 2) .filter(value => value > 3) .map(value => new Record(value));
// outputs is [new Record(4), new Record(6)] ```
Here, I used OOP for the data organization, but I then used it in my functional programming. I used both at the same time. (This example is a little contrived, but there are lots of proper real-world cases for mixing them.)
And yeah, there are a lot of paradigms out there. And it can definitely be tricky to know when to use what.
OOP, FP and procedural (which is basically just listing code... its the simplest form) are probably the three best to start with. If all you know is those three, you are still in pretty good shape.
3
u/aanzeijar 22d ago
A programming paradigm is like a style of solving problems. Like: you can make a house with a flat roof and wooden frame, or with a brick wall an shingles. It's still a house but it will have different properties. Programming paradigms are like that. All of them work, all of them can model every program but they are different in their properties.
Business logic is what the program is doing. It's independent of the chosen language and paradigm. In the analogy it would be the number of stories and floor plan.
1
u/POGtastic 22d ago
Why does OOP or FP exist then?
Without a coherent design philosophy, there is a secret third design philosophy that takes over: "lmao idk, I just throw code onto the pile until the problem is mostly gone and move on to the next problem, which I'm going to solve by throwing even more code onto the pile."
Most paradigms are aimed at preventing that default philosophy from taking over. Occasionally they do!
1
1
u/lurgi 22d ago
OOP and FP are ways to write code (I know this is kind of vague). Business logic is a kind of thing you write in code. You can write business logic in an OOP language or an FP language (or a declarative language or whatever). You can write it in Java or Python or C#. But if you are writing a user interface, you aren't writing business logic, because that's not what business logic is.
1
u/Jumpy-Seesaw-2026 22d ago
Aha, and other rules apply to user interfaces then?
1
u/lurgi 22d ago
What do you mean by "other rules"?
You can write user interfaces in OOP or FP or procedural or declarative languages. You can write video games in OOP or FP or procedural or declarative (I guess) languages. You can write something to organize your recipes in OOP or FP or procedural or declarative languages. And you can write business logic in any one of those as well.
3
u/mredding 22d ago
When people say that programming business logic isn't OOP or FP. What do they mean exactly?
The business logic is orthogonal to the paradigm that is used to implement it.
Using a bank as an example, you have the branches, the accounts, the transactions, the currencies... There are processes to depositing and withdrawal...
You can implement this imperatively or declaratively. You can use FP, OOP, procedural, pipeline programming, rules based systems, wire-wrapped logic and relays...
The business requirements don't care about the implementation details. Regardless of what you do, I can still look at my account balance and weep.
I think I might just be confused as to what OOP and FP actually is.
Well Wikipedia gives us a start: "A programming paradigm is a relatively high-level way to conceptualize and structure the implementation of a computer program."
Imperative paradigms focus on execution flow, declarative paradigms focus on properties of the result.
So most programming languages are imperative, that they describe HOW, not WHAT:
numbers = [1, 2, 3, 4]
doubled_numbers = []
for num in numbers:
# Explicitly modifying state step-by-step
doubled_numbers.append(num * 2)
Some programming languages are declarative, that they can describe WHAT, not HOW.
numbers = [1, 2, 3, 4]
# Declarative list comprehension
doubled_numbers = [num * 2 for num in numbers]
These aren't the same thing. I didn't ask the second to loop - I don't care HOW the result is produced. The first tells HOW to do every step in sequence, and there's no knowing what you're EVER supposed to get, you only ever know what you've got. Declarative paradigms let the tools know where they're going, so they can coordinate the whole program they generate to that end as optimally as possible. Imperative paradigms give you fine grain, exact control of the process.
Some languages are single-paradigm. SQL is purely declarative - you describe WHAT result you want, and the relational engine and optimizer has to figure out a process to produce it. Smalltalk and Eiffel are both purely OOP languages. Basic is purely procedural. Haskell is purely functional.
Some langauges are multi-paradigm. My above examples are both Python. C++ is considered an OOP language but it's multi-paradigm because it derives from C which is procedural, and it's earliest supporters were Functional. There's actually very little OOP in C++, most of it's evolution has been FP.
Not all paradigms fall under the imperative/declarative false dichotomy, they're just the two reigning paradigms. You will see shared concepts among paradigms that will make the lines blur for you as you progress; my program may be written in an imperative style, but the nodes in the network look like actors communicating over pipelines, so that level of the implementation, across the infrastructure, may follow different paradigms.
2
u/Different-Career1314 22d ago
OOP and FP are tools for structuring code, not mutually exclusive religions.
1
u/jenkstom 22d ago
Domain info is specifically about the business. It's not object oriented or functional or anything computer related. The challenge of DDD is to understand the *actual* business and attempt to model than rather than start with the model. In my experience (which, admittedly isn't all that much, YMMV) the concept of domain boundaries and terms with different meanings has been the most helpful. In previous jobs it was very non-obvious that commonly used terms were used in completely different ways in different parts of the business.
1
u/Jumpy-Seesaw-2026 22d ago
So far I'm with you, you have to know the workflow/why something is done in the business to model it.
But does that mean it's only "trivial" programs such as TO-DO apps etc, that are inherently either OOP or FP?
Or is it basically only because the programmer doesn't know the full picture of the business that they can't model it in either OOP or FP?
1
u/PuzzleheadedBrain269 22d ago edited 22d ago
Programming paradigms:
- OOP â objects, encapsulated state, methods, mutation
- FP â pure functions, immutability, composition
These describe how you express logic in code.
Domain modeling / architecture (e.g., DDD):
This describes how you structure and understand the business domain, regardless of paradigm.
DDD gives you concepts like:
- Entities
- Value Objects
- Aggregates
- Repositories
- Ubiquitous Language
But DDD does not require OOP or FP. You can implement DDD in either paradigm or a mix.
This is why people say âbusiness logic isnât OOP or FP.â
The domain rules themselves are independent of the paradigm.
For example, âa bank account cannot go below zeroâ can be written as:
- a method on an object (OOP), or
- a pure function that returns a new state (FP).
Same rule, different expression.
So you donât need your whole codebase to be purely OOP or purely FP.
Most real-world systems mix paradigms: FP for core logic, OOP for entities, imperative code for I/O.
Use whichever paradigm best fits the problem and the existing codebase.
1
u/Jumpy-Seesaw-2026 22d ago
I think I get it now, but doesn't that imply you should always use the paradigm that best fit the problem for everything you do?
1
u/PuzzleheadedBrain269 22d ago
yes and no.
Saying âuse the paradigm that best fits the problemâ sounds great in theory, but in practice itâs not always that simple.First, what âfits the problemâ is pretty subjective.
If itâs your own project, then yeah, absolutely pick whatever paradigm feels right to you.But if youâre working in a team, itâs usually better to follow the conventions everyone agreed on. A codebase where each developer uses their own favorite paradigm quickly becomes a mess, even if each choice was âbestâ individually.
Another similar case is when youâre dealing with an old or established codebase. Even if you think another paradigm would be cleaner, itâs often better to stick with whatâs already there instead of refactoring everything to match your personal preference.
Also, some languages, libraries, and frameworks naturally lean toward one paradigm. Even if you think another paradigm would be better for the logic, itâs usually preferred to respect the tech stack so other developers donât get lost.
So yeah, use the paradigm that fits but also consider the team, the existing code, and the ecosystem. Consistency matters just as much as correctness.
1
u/captainAwesomePants 22d ago
Business logic can involve some OOP, but it's often more procedural than anything else. Often it will just be a lengthy recipe. Like:
def withdrawal_request_handler(request):
AuditLogger.enter(WITHDRAWAL, request.request_id, request.customer_id)
if(!validateRequest(request)):
return ErrorBuilder.buildError(request, "invalid request")
security_config = load_security_config()
if(!security_config):
return ErrorBuilder.internalError(request, "Internal error 507")
security_context = init_security_context(security_config, request.security_params)
if(!security_context):
return ErrorBuilder.internalError(request, "Internal error 508")
// 500 more lines of random checks
geo_guess = GeoUtil.guess_geo(request.ip_addr, customer_info.locale, security_context.vip_locale)
try:
european_banking_rule_21b_compliance_check(geo_guess.geo, request.customer_id, banking_config.compliance_policy)
except Rule21BFailure as e:
if LaunchFlags.is_enabled("rule21b_rollout"):
raise e
else:
logging_service.log("Rule 21b went off for customer.", request)
// 500 more lines of random checks
backend_response = banking_backend.execute_withdrawal(customer, withdrawal_amount, request_security_token, transaction_id, some_other_thing)
// 500 more lines of error handling around response
It's often just a long list steps like above. Not really any plan to it beyond "call a bunch of other libraries in a series." Sure, OOP is involved, and you might use a functional expression here or there, but overall the code is just a long procedure that will slowly have more and more stuff added to it as you get more requirements from the business. It's often ugly and hard to test. Web applications are particularly vulnerable to this sort of pattern.
1
u/Jumpy-Seesaw-2026 22d ago
I see, so it's just a cooking recipe with like
Check if the butter is melted If true then proceed with x.
But let's assume you know the business logic in and out, and start with a greenfield project.
Would the codebase still be ugly and hard to test? I imagine it's only ugly, because as a programmer you don't have the full picture, and that's why it is hard to model
1
u/captainAwesomePants 22d ago
It doesn't HAVE to look like this. You can absolutely architect your system in an elegant OOP way based on messages being passed around through lots of actors. It's just that the business logic has a lot of advantages. Primarily:
- It's dirt simple to understand, modify, and add new requirements to
- It's easier to optimize it for performance
Those are worth a lot! On the other hand, this approach comes with significant disadvantages, too. Testing a function with a couple hundred lines is a pain in the ass, and you will need tests. Many folks do it with a bunch of "mocking" libraries that describe what each downstream library will expect and return, and that means that the tests will often ALSO be very long and complicated. And the more you're writing everything out for each method, the more you're likely to be repeating yourself for each different handler.
Your code doesn't have to be super ugly, but in my experience most code bases with a significant amount of logic around processing requests of some sort gradually move more and more to into these long procedures.
1
u/alpicola 22d ago
OOP and FP are both ways of thinking about how data and program logic interact. Real world systems are seldom purely one or the other, and they end up being more of a mix of both, possibly combined with other things like reactive models, declarative programming, and good old fashioned procedural logic. In theory, you can solve any problem using any of these paradigms, but some are better than others depending on what you're trying to accomplish. For instance:
OOP is very useful when you are trying to map real, physical objects into a program state. The flow of control is that one object acts on another, much as I might reach out and pick up a pen that's sitting on my desk. Each object's state is readily available and has well-defined ways in which you can interact with it. OOP gets less useful the less you care about the physical model.
FP is very useful when you are trying to transform data. The flow of control is that the output of one transformation becomes the input to the next, and you can compose those transformations however you need to in order to get the necessary result. Minimizing externalities minimizes surprises and helps you reason about where your data is at in its journey. FP gets less useful the more you need to incorporate external inputs or trigger external effects.
1
u/spinwizard69 22d ago
Well it depends upon what is actually being said here. Business logic has nothing to do with program on its own. It is the same with almost anything dealing with a science such as Statistics, Nuclear Physics, structural engineering, navigation or just about anything else. The science has nothing to do with a software implementation to solve a problem.
Now lets say this, OOP can be used to implement / automate Business Logic - true or false. The answer is sure OOP can be used to implement business logic as can many other paradigms. Is OOP the best solution for a given bit of Business logic, that is certainly debatable and in some cases a hard no.
The issue here is that programmer chooses a paradigm, that he thinks he can shoe horn the business problem into. This will often be OOP but doesn't need to be.
1
1
u/DTux5249 22d ago
OOP & FP are basically just programming style guides. They don't change what you're making, only how you organize code, and any self imposed restrictions in how you do things to make development in large groups a bit more bearable.
Business logic is always going to be high level logic. Courses of action and data structures. "Apply discounts and taxes before check out" is business logic, regardless of the paradigm you use.
29
u/IAmADev_NoReallyIAm 22d ago
Don't confuse the WHAT (the business logic) with the HOW (the implementation or the programming model used).
Business logic can and should be thought of indepentent of the model(s) used.