I watched a programming discussion using a bank account as an example. The account is represented as an object with methods such as deposit() and withdraw() that mutate its state. My understanding is that object-oriented programming and functional programming are different ways to structure a solution to the same problem, so I'm confused when people say business logic itself is not OOP or FP. What is business logic considered in that case? Does an entire codebase need to follow a purely functional style to be called functional, or can a project mix paradigms? Is domain-driven design an intermediate philosophy, or is it solving a different problem altogether?
4 Answers
OOP and FP are not mutually exclusive camps. A real application might use objects and encapsulation around some parts, pure functions for calculations and validation, and ordinary imperative code for database calls, networking, and other side effects. Most languages support several styles, and most production codebases are mixtures. You do not need to make every file purely OOP or purely functional for one approach to be useful.
Business logic is the set of rules the software is supposed to implement—the “what”—not a programming paradigm or a particular kind of code. OOP and FP describe different ways of expressing those rules—the “how.” For example, “an account cannot go below zero” could be implemented as a method that mutates an account object, or as a pure function that receives an account state and returns a new state. The rule is the same either way.
That distinction helps. So OOP and FP are ways to organize and express the rules, rather than categories that the rules themselves belong to?
Sometimes business logic appears as a long procedural workflow: validate a request, load configuration, perform checks, call another service, handle failures, and record an audit event. That code may use classes and functions internally, but its overall shape is simply a sequence of steps. This does not mean the business rules are inherently procedural, OOP, or functional. It is just one implementation, and poor separation of concerns can make it difficult to test even when the business is well understood.
So knowing the domain better can lead to a cleaner model, but it does not guarantee that the result will naturally be OOP or FP. Those are still design choices for expressing the model.
Domain-driven design is about understanding and structuring the business domain, not about choosing between OOP and FP. It emphasizes things such as domain terms, boundaries, entities, value objects, aggregates, and business rules. Those ideas can be implemented with objects, functions, procedural code, or a combination. DDD is therefore complementary to programming paradigms rather than an intermediate paradigm.
Choosing the style that fits the problem is useful, but consistency and maintainability matter too. A project can mix paradigms deliberately instead of using a different style for every small piece.