Yes, of course, when SOA issues are resolved and many of the details have been discussed

We jump right into DDD

However, I deleted all the articles I wrote about DDD before, because the response was not very good, no matter in Zhihu or Nuggets

I spent a lot of time thinking about it, and finally something came to mind, which is —

The term DDD is so misleading

It’s English, it’s short for domain-driven design, and it’s tied to technologies like microservices (the microservices way of thinking), and it feels alienated, complex, and different from the mainstream way of working

However, the essence of DDD is actually quite simple, even to say:

You’re using DDD development architectures when you can’t program at all

Or even more

Business Oriented Development – Develop with the mindset of a product manager

The most natural development way, the simplest development way, the most should form the development way, is DDD, in order to prevent misleading, later all called – business development

I haven’t learned anything, I haven’t heard of any technical terms. If you look at science novels or product reviews, the way they think is the way you think in business development — if you say there’s light, there must be light!

There is no need to learn this approach, as long as you have the concepts of flow, composition, inclusion in your head, you have learned DDD, an architecture that is already widely used on other platforms

What can you learn?

** Learning how to do is not BUSINESS development (DDD), i.e. what is bad smell **

Yes, this is the most primitive, purest way of development, and the reason why it can’t be used is because of infrastructure!

Developers of JAVA and other platforms simply sum up DDD as a return to essential object-oriented

People who understand design patterns will think that DDD is all about adapters

With poor infrastructure, it’s easy to get bogged down in third-party libraries, historical code, and domain-specific development thinking that prevents you from achieving what you see is what you get + what you think is what you write

React, for example:

  1. Data driven is the most simple to implement, because regardless of the Shared memory communication asynchronous, or will it be the CPU resource processing, are to implement to the data, realize the end is very strong, but he is out of our behavior modeling (note that is a behavior modeling, not structural modeling, runtime problem with state simulator to is too abstract, can see in the above example)

  2. Older versions don’t have a good implementation for cross-component logic (reusing state logic between components is very difficult, according to React)

Because of the infrastructure support issues, developers had to translate events into states (which they still do, but with control) at development time, or even push the state to the global level, cutting the entire application architecture apart

This is a problem caused by weak infrastructure, the so-called traditional MVVM architecture, and you already know that in DDD, there is no design pattern, the whole application is just one side of the adapter, the view is your adapter, the request is your adapter, you just need to understand and arrange your business code!

Yes, TDD with DDD, you only write business code, then you can only test business code — @testing-library/react-hooks, only then does test drive make sense, between one view and one VM, two layers of boots ticklish, virtually no usability, Tired and useless

You don’t have to worry about initialization — dependency injection, or view response — declarative responsiveness. You just have to worry about your own logic — scheduling/algorithm/data/events

With this general understanding, we can sort out the problems that follow

Such as split code (generalization of the relationship, aggregation, combination, associations, dependent on), such as run time scheduling plan, namely relationship between events (such as merger, competition, delay and differentiation), and problems such as architecture structure (bounded context, field events, value objects, child domain, etc.), and the working process problems (test drive, storm events, etc.), Finally, there are practical applications (microservices, high availability, etc.)

The new architecture of all of this is based on this

Technology provides possibilities – developing business-oriented DDD possibilities gives you the assurance that you can take logic out of the code

Right, so the next discussion, it’s no longer about software development techniques, it’s about how to arrange your code — that’s not development techniques, that’s just strategy, right