When should we not use a domain-based approach?

Question

I read about the DDD that I came across with this paragraph

For data centering operations, you probably would be better off using something like an Active Record Sample or even a DAL on stored procedures. You may find some advantages in some of the more superficial aspects of DDD and perhaps the use of some terminology, but trying to make DDD suitable here will not be a pleasant experience.

as well as this one:

Probably 95% of all software applications are classified as "not so good for using DDD." Most of them are based on Data Centric - most websites, most desktop applications ... basically most data updating and reporting applications are data oriented.

So what do you think? Do you accept this opinion? According to these points, we could not use DDD for a wide range of IT projects, could we?

Answer 1

Take these numbers simply as some values ​​based on the experience of the author (Evans book was published over 13 years ago, since then the situation has changed).

First of all, what (unfortunately) few developers understand is that DDD is a way of thinking, a way to look at things. It. Thus, you can use DDD in every project, because we still need to understand the domain first, regardless of its implementation. If it turns out that the domain is just a bunch of data structures, then you do not need to complicate your life. Especially if you are creating a "silent" application, that is, the user interface for the database.

But if you are creating an application that needs to understand business semantics (concepts and behavior) in order to automate things, then this is a different story, and all these DDD concepts will help you create a more convenient application.

So it really depends on your application, and even in this application everything can vary greatly. You must first understand the purpose of the application, and then the domain that it is trying to represent (if so), and come up with a solution for each use case. In one application, you can have many CRUD materials, and you can be very effective, leaving a lot of abstractions and , you can have a couple of important concepts and use cases that will require a much better understanding and design. It is also important how you think the application will change over time. If there are signs that it will develop over time, it would be better to be a little distracted, but only in terms of design. At the moment, the implementation may be CRUDy.

If you consider a methodology as a group of thinking and concepts, you can use it everywhere, because something like DDD is not an “how to” coding recipe. Although he has certain tools, the application developer must decide whether they are good for your application.

Simply put, you need to use DDD to decide if (integer) DDD can be used for some parts of your application. But then again, DDD means a strategic approach, thinking.

It’s just not right to solve the solution from the very beginning for the entire application. Understand the problems that the application is trying to solve and use the appropriate solution for each problem. If, after all, everything is just CRUD, then everything is fine. It is also normal, if only some parts are implemented using tactical DDD tools, the task is to have an optimal solution to the problem.

In conclusion, learn and understand the DDD mindset (there are a lot of explanations, focus on the design, not the recipes, because they are wrong), avoid looking at his coding recipe and just use it to determine the best approach for applications.

Answer 2

Vaughn Vernon, in his remarkable book, resurrects the rate of DDD .

If your application is specifically CRUD oriented, DDD will be YAGNI.
Otherwise, if your application is really task-oriented, having caught the user's specific intention, DDD can really help you.

Answer 3

DDD is a collection of ideas. When you talk, use it, I'm not sure what you are talking about. For example, the ubiquitous language is probably a good idea if you map business to code. Value types may also be useful.

But ideas such as limited context and cumulative roots? Well, developing in this style will be of great value, because the design naturally becomes more complex. And in some problem areas, it is necessary to isolate the domain problem. And this is because the problem is complex. In other words, 95% of systems do not solve complex problems that require complexity costs.

I like to think of DDD as existing within a kind of project spectrum.
Sort of:

<--CRUD----Active Record----Domain Model----DDD--> 

From left to right, these ideas grow in complexity. And you naturally move from left to right when you design the code. It is good practice to defer design decisions (architecture) as long as possible. So, you can always start with something on the left and move to the right.