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 :)
DDD has its own concepts and design which, strictly speaking, are independent of the object orientation paradigm. I suggest you read this answer: http://answall.com/a/40962/14584
– Caffé