Original: Taste of Little Sister (wechat official ID: XjjDog), welcome to share, please reserve the source.

Niu B’s characters, already tired of mixed Chinese and English, they go one step further, using Chinese and English abbreviations, to the common people to reduce dimension. Even better, make up new nouns and popularize them.

There are several technologies, I despise and hate from the bottom of my heart, but every time in the technical plan, they are silently added, and give them full weight. Because they play an important conceptual role in guiding the success of the solution.

These are mid-stage, low code, and DDD. The technology in these three different fields has the same responsibility, which is to fool people into death. Those three words, they’re great, they have one thing in common, they’re all very easy to sell to non-technical people who can make decisions, and then they roll down, very marketing, very popular with professional managers and Ctos. It’s also a favorite of consulting firms.

Some of these things can fool big companies, some can fool small companies, and no one can get away with it.

But if the cancer can bring us benefits, of course, also want to embrace. Don’t be so rigid.

When the evil wind comes, instead of closing the window, we embrace it and embrace it! Why some people’s wages are high, some people rise quickly! Some people become masters! Think about the root cause.

Concepts can sublimate systems

You know what? The more senior you are, the more likely you are to like something ethereal. Take the ancient emperor for example, there are many expected to meet with the gods, was cheated by the fangs alive and dead. Even if finally know to be cheated, also can secretly block up the message. Recently, I found a lot of such cases.

First, they really want it. Second, is afraid of these things were exposed to lose face, can only stick to it.

There is nothing new on earth, even in the software industry. When we deify something, endow it with supernatural powers, it makes its way down the path of the enchanter.

How to deify? Grasp the pain point, talk about vision, do methodology, generally can sell success.

Of course, sales success is only the first step, we also have to avoid failure, to avoid being judged. So we need to motivate decision makers so that they recognize their shortcomings and are ashamed to admit their weaknesses, and then we are on steady ground. As soon as the decision-maker gets on board, he tries to beautify it, fight for more resources and get more people on board.

The reason why Internet slang is so strong is because it can be fooled and sublimate your mind, not hollow code.

Let me give you an example.

One company, with a limited number of people working on it, had a lot of work spread across multiple systems. The research and development department came up with the conclusion: to focus, focus on the core system. How to do? You can’t just write “focus” on your POWERPOINT, it’s too LOW.

I thought about it, and suddenly I had an idea. Why don’t we make up some nouns. According to the level, it is divided into CVP system, IVP system, EVP system. In this way, all of a sudden forced case rose a lot.

Can’t read these nouns? If you can’t read it, it’s good, because I built it, and that’s what I want.

If you look at the diagram below, you can even attribute it to one of these three categories.

Importantly, the focus of the business systems, transformed into the focal point of the CVP. Haha, we can talk for a long time now, instead of making a quick decision.

“Teach you how to talk for ten minutes and you haven’t said anything.” This is a very important skill.

So, let’s see, what are these technologies? Why cancer? Why embrace them.

D not D D D, what difference does it make

It is nonsense to say that being domain-driven means designing systems according to requirements.

Do you have any Demo code?

Do you have any Demo code?

Do you have any Demo code?

Do you have any Demo code?

All the articles are filled with such questions. If the DDD layer is strategically useful, it should not be a programmer’s toy, it should be a requirement analyst’s toy. DDD should learn TOGAF, COBIT, CGEIT, etc., and focus on strategic layout, not on the fate of programmers and tactics.

If you stick to your business training certificates, you make your money and I do my architecture, we’ll be fine. But if you put your tentacles on my turf, you’ll attract trolls like me.

The right way to open up DDD is to embrace its strategic phase and discard its tactical phase entirely. Do this, and you will live a good life. Forgive me for using terms like “bounded context” : once you’ve defined my service boundaries, you don’t care how I implement them, design patterns and architectural patterns. I have a toolbox full of terms like CQRS and event traceability.

The concept of DDD first came from 2004, so many years of no popularity, no standard landing, not for nothing. In recent years, some have discovered the impoverishment of technical terminology and picked it up again in the hope that it will continue to work for KPI.

I was obsessed with DDD, tormented by its promise. Bought online courses, bought books, and finally found it was a waste of my time. I hate it. To tell you the truth, a technical solution that is difficult and difficult to implement does not qualify people to divide their energy to understand it.

I’m sorry, there’s no road to powder.

First of all, DDD is a volume in volume company, it is not like microservices technology, can find a large number of implementation solutions. In fact, you can hardly find any useful reference examples, let alone one another. It is like the Bible. It tells you what is right, but how to do it is up to you.

Why can’t you do DDD? Why can’t your team do DDD? DDD gives three main reasons.

  • High requirements for the team. Voice-over, if you can’t do it well, your team can’t

  • DDD is only effective for complex businesses. So what is complexity? The jury is still out. Voice over, if you think it’s not working, your business isn’t complicated enough

  • Although you can not use DDD, but the ideas, or worth learning and thinking. Voice-over, I’m a master of all things. I won’t let you learn for nothing

No one will admit that their team is not good, no team will admit that their business is simple, no one can tolerate their own investment is really meat dumplings beat dog. DDD instantly binds you together with several reasons why you shouldn’t punch your face.

In 2020, I had the honor to read the book “Realizing Domain-Driven Design” for three months and marveled at its profound level of word use. Later, I knew how to document even a simple CRUD project, and this book was a good example.

You search the DDD article, no matter what article, there is a feature, that is not good to speak human words. All the application code is a pile of unconvincing junk code. Because developers find themselves looking for pain when compared to normal writing, why use it?

Take the fancy hexagonal architecture for example.

The hexagonal structure, because it looks like a honeycomb, looks very close to the green nature, very tall. To be honest, I still have no idea what the difference is between hexagons, octagons (no such thing), and triangles (no such thing), and why these noun buffs chose the number six.

You say, complex business logic, should not pay too much attention to technology and other infrastructure, but to reserve interfaces on the line, must be so mysterious, one earthworm like line radiates from the rotting hexagon. Think it’s beautiful? Maybe the boss thinks so, because the rainbow noun wheel does scare a bunch of blasters.

Not to mention the separation of ServiceMesh’s data plane from its control plane is guided by DDD, although it is conceptually dependent.

The following figure shows the Hexagonal Architecture in Google search.

Ouch, where’s the hexagon? Why does this graph have a 10-sided shape? Is that still a hexagon? Are you fooling children? When I can’t count? What, you call it onion head architecture again, they’re not the same thing? Such misconceptions are common in DDD, and I don’t want to explain them because they are short stories. This shows that it is a comprehensive deception methodology, started by piling up concepts and slang, and the propagandists are not qualified.

The whole DDD set of concepts, values is problematic. Or maybe the author’s intentions are good, and it’s a complex business. As a result, this group of propagandists and training became necessary to solve the problem.

But I’m sorry, you’re not qualified to teach others architecture because you don’t even have a smooth communication.

Embarrassing situation

Awkwardly, the people who really need DDD don’t agree with it; People who don’t need DDD are forced to identify with it.

The biggest value of DDD is to sort out business requirements, classify different business domains, and form interface interactions between domains. To be honest, I’ve met a lot of consulting bigwigs who scoff at the idea of a one-size-fits-all methodology, preferring to use older methods of business combing like TOGAF. But all roads lead to Rome, and the final demarcation can be agreed upon.

These grooming processes are largely the domain of business experts and systems architects. Their work will be implemented as input and output to the technical team. They need DDD, but they don’t use it.

The tactical phase of DDD, by comparison, is worthless. For example, I don’t need to know the concept of CQRS to work just fine by aggregating data into a wide table or big data center to form a data “middle station” that provides a separation of the transaction domain, the management domain, and the query domain. As for the entity congestion is not congestion, I was originally micro service, business granularity was very small, how to write is my freedom, transformation is also my own cost, I do not need to follow your set. Talk about business and technical communication? I’m sorry, I’ve never met a team that can’t communicate to do business.

Engineers are forced by decision makers to use DDD tactics to write business, resulting in more messy code and more frequent changes. But DDD said, sorry, it’s not my fault, it’s your team.

That’s true, but in reality, there are still people who brag about it and even use it to modify code. The book “Microservices Architecture Patterns” even has two chapters, event Traceability and CQRS, to explain some of the implementation of DDD. It’s called the master poisoning the master, and it’s also called helping each other.

With all due respect, if you buy that crap, you’re probably killing the program. No book is better than all books. Architecture is a trade-off, and there is no one-size-fits-all guide. You can refer to it, you can think about it, but you can’t copy it, because every company’s technical premise is different.

Having said that, when some concept is touted, it can cause problems if you don’t embrace it. There are two difficult problems in the software industry. One is how to report complex things simply, and the other is to make simple things complicated. For the former, it’s about the feasibility of your idea. With the latter, the main goal is to look lofty, mainstream, as obscure as possible. The former feet on the ground, the latter mouth lotus.

The latter is obviously much more effective than the former. Let a person sound to feel very cool x, but don’t understand, can get applause, can also experience the feeling of high above. No one’s going to admit they’re not smart enough, and you need to energize those people. As long as someone agrees, it can generate benefits.

Some concepts, some people, are not god, but the community of interests requires him to be god. These things have believers, too. Can you believe that? But aren’t software design tools used when appropriate and thrown away when not? Why did you become a believer? Just getting on the boat.

In some ways, my friends, DDD is not that different from, say, bitcoin. This is the magic of faith, this is the power of the master ah!

End

Only an honest man like me sprays once in a while. Then I turned around and wrote DDD on my solution. Yes, I can write, I can talk, I can think, but I will never use it lightly.

It’s the only time I advertise it as my own dad.

Xjjdog is a public account that doesn’t allow programmers to get sidetracked. Focus on infrastructure and Linux. Ten years architecture, ten billion daily flow, and you discuss the world of high concurrency, give you a different taste. My personal wechat xjjdog0, welcome to add friends, further communication.