What is the difference between OO and DDD?

Question

I read about Domain Driven Design, it seems to use the concepts of object orientation but is based more on business rules. Is there nothing else that actually differentiates OO from DDD? If it is possible to illustrate how this reinforcement of business rules is done compared to OO.

Answer 1

Actually there are differences between OO and DDD, but both fit. Quickly explaining:

• OO is a paradigm of programming and modeling whose purpose is to realize an abstraction of the functioning of the "real world" for computational systems. That is, it uses classes, objects, methods, etc. to simulate an interaction between real-world elements in a computer in a more natural way.

• DDD is an approach to software development where there is a great focus on the domain. In order to develop a software for a specific domain one must use an OO language, because it is perfect to represent and abstract the domain studied in a computational system.

Answer 2

I decided to answer because I have been studying the subject a lot and almost everything written about it recently does not convince me. I find much of what is reported about Ddds or even Aos to be flawed or unsustainable.

I don’t like this idea of O wanting to represent the real world. I know you’ve always sold this idea, but it’s flawed and leads to learning and doing wrong things in this paradigm. We can’t reproduce the real world, it’s too complex to do this. And it’s a shame that examples of object-oriented code try to do just that by teaching people to inherit where it doesn’t fit. Have you noticed that most of the examples are related to biology, and that almost no problem in your code is biology? In biology it’s easy to inherit, as long as you ignore almost everything that actually happens there.

In general OO is good to build mechanisms already abstract and in some cases simulate concrete objects in a very simplified abstract form. So using OO in GUI or games or other mechanisms that only exist in the computer is very good, but to model the real world we need to make adaptations.

An example is a class Pessoa, we cannot represent a person actually there (it is too complex to reproduce it in a class), we can make an abstraction of what is important to our problem about a person, only this. So we can have fields and methods in this class to give what we need. And because of this misconception people think that a Cliente is a Pessoa and make inheritance, when it is not, but the client is an abstraction of a relationship (something already abstract), probably commercial, that a person has with an institution or mechanism, so it even has inheritance relationship as everyone does, and people do it because they learned from the bad examples of OO.

It’s not just a matter of simulating the real object, it’s making an interpretation of that object and its role in your system, and this is not easy in business domains, one of the reasons I criticize a little the extensive use of OOP for this type of application (nothing against doing for the application mechanisms, but complicates a little do the same with the business rules, and to do right tends to complicate the application a lot, and yet to do right it is necessary to have a very large domain (could not miss doing this :)which almost no one has).

And I’m an even bigger critic of D.O.D., especially from what I just said. I’m not saying it should never be used, but I’ve never seen it work with evidence of this. He’s great on paper when it’s a dream, but practice is much more complicated. And I’m not saying that we don’t learn good lessons by studying the subject and that we can’t apply some things of methodology.

It is true that DDD uses OOP techniques, but at the same time some things it preaches are somewhat against what OOP should be (which may be even good, nor put this as criticism, OOP is not this panacea that almost everyone is sure it is, even sometimes making speech that is not). In fact this discipline improves some things, but it encourages others rather rash to do, not for nothing that some who tried to implement live nightmares. And nothing indicates that DDD only exists in OO languages.

Anemic model goes against OOP, as well as functions without side effects, breaking what should be the same object into different objects, just to quote what violates OO, has other things he has to do that is contrary to all knowledge acquired for decades in the process of software development.

And just because the DDD creator said certain things doesn’t mean they’re right. Of course, if you don’t do everything he says you can’t say you followed DDD, but following DDD faithfully is no guarantee of having made a design better, easier to maintain, cheaper, flexible or with any feature that try to sell with it. In the end the people involved know what they are doing and understand the whole process will always be the determining factor whether it will be good or not.

DDD is a very good idea, but the way they have implemented it is terrible.

Because of these points I all disagree with the accepted answer, except that DDD is more about the domain. Until OOP is something about classes I disagree :)

Answer 3

I agree that domain objects will always be indebted in relation to real world domain representation and no one will be able to model this domain as well as this, even because in the real world this domain is always changing and being adapted.

For me OOP facilitates not because it is an abstraction of the domain but because it brings some good practices of how these objects should communicate with each other.

I say this thinking about the GOF in the creative, structural and behavioral patterns.

How these objects are constructed, grouped and communicate with each other.

About DDD I think the idea is from the model build the solution of my system.

First I represent the entities closest possible to my real model (that business process that already exists elsewhere and that someone already performs, either with excel spreadsheets without having a system for example)

That is, I model and then I will adapt my algorithm that will solve a problem.

And I don’t create an algorithm and then adapt it to my business model.

I guess that’s it.

Well, that’s what I understood of what you put up.

Abs

Answer 4

It’s easier to see the difference if you look at DDD as a guide that guides you in designing the logical solution and OOP as a way to implement this logical solution.

DDD helps you make decisions about how to think and understand what the problem is actually to be solved and how to propose the most consistent solution possible. While OOP is a paradigm that allows the implementation of the concepts and practices suggested by the DDD through a programming language.

With DDD you learn more than just modeling the domain and creating repositories, it addresses important architectural decisions for system quality and support. It helps you think earlier about things you usually only think about once you’ve started. For example, the names we use for things (ubiquitous language), what are entities and what characteristics are important to it within the context, what are value objects, how to divide the system into subsystems (bounded context) so that different people collaborate with the same system in parallel, as these subsystems will relate after being separated, etc.

Object-Oriented Programming comes after these decisions, when you start implementing the solution and need a language that provides you with the resources to work with concepts of encapsulation, polymorphism, inheritance, packages/namespaces.