I watched a programming discussion that used a bank account as an example: the account is represented as an object, with methods such as deposit() and withdraw() that can change its state. My understanding is that object-oriented programming and functional programming are different ways of structuring code to solve problems, so I'm confused when someone says that business logic itself is neither OOP nor FP.
Is business logic simply the set of business rules that the code must implement, independent of any programming paradigm? Can the same rule—such as preventing a bank account from going below zero—be implemented either as an object method or as a pure function that returns a new account state? Does an entire codebase need to follow a purely object-oriented or purely functional style to qualify as OOP or FP?
I'm also wondering how domain-driven design fits into this. Is DDD a separate or intermediate design philosophy, or can it be combined with either paradigm?
3 Answers
Domain-driven design is concerned with understanding and modeling the business domain: its terminology, boundaries, entities, value objects, aggregates, and rules. It doesn’t require either OOP or FP. You can apply DDD concepts using objects, immutable data and functions, or a mixture of both.
The important part is understanding what the business actually means by its terms and processes before choosing a code structure. The same word can even mean different things in different parts of an organization, so identifying clear domain boundaries is often more valuable than immediately choosing a programming style.
The key distinction is between the *what* and the *how*. Business logic is the set of rules and processes the business cares about; it isn’t a programming paradigm by itself. OOP and FP describe different ways of expressing those rules in code.
For example, “an account cannot have a negative balance” could be implemented as a method that mutates an account object, or as a pure function that receives an account and returns an updated account. The rule is the same even though the implementation style differs.
Real applications commonly mix paradigms. A system might use objects around infrastructure and stateful services, functional code for calculations, and ordinary procedural code for coordinating steps. You don’t need the entire project to be purely OOP or purely FP.
OOP and FP are tools for organizing code, not mutually exclusive categories that every piece of logic must fit into. Most languages support several styles, and most real-world codebases combine them.
OOP tends to emphasize objects that encapsulate state and expose operations. FP emphasizes transforming data with composable functions, ideally minimizing mutation and side effects. Both can model the same domain; the better choice depends on the problem, the language, and the surrounding system.
So calling someone an “OOP developer” or an “FP developer” is usually about their preferred style and tools, not a requirement that every line of their code follow one paradigm.
That clears up the distinction. I was treating the rule itself as if it had to belong to one programming style, instead of seeing the style as a choice for implementing it.