In DDD, Senior Infrastructure r&d engineer Bai Yan takes you from zero to one to practice the top-down business driven architecture!

🎙️ Author introduction

Bai Yan, senior infrastructure r&d engineer. I’ve done testing, written business systems, and now I’m mainly responsible for infrastructure development.

During these years of work, I have done test architecture, MVC business architecture, and of course I have also implemented DDD hexagonal architecture.

If you’re asking me if I’m a veteran tech guru, I’m definitely not. I am just a “blind man crossing the river by feeling for stones”. However, because of this, I have passed the test of actual combat on the way of infrastructure implementation and experienced the polishing of business. I hope to provide ideas for infrastructure implementation from the perspective of more fitting business and practice, and grow together with everyone.

🔥 Why study DDD?

I don’t know if you get the feeling that, no matter what company you work for, if you’re working on a project that’s been maintained by multiple people for more than two years, there’s always some sort of “bad taste” in the code.

Commonly known as: “predecessors dug pits, posterity filled pits.” If you think about it for a moment, is this a normal way to develop requirements: start with the table structure, then CRUD to assemble function points from the table data? The nature of this “shit mountain” of code is that the business logic is so chaotic that the code is piled up in order to accomplish a function point.

No, you’re not developing the whole system from a business perspective, you’re developing the whole system from a data perspective. The database table is also a very sensitive thing, will not easily change the table structure. In order to meet increasingly complex requirements, you can only add tables, fields, and if/else logical nesting. Over time, your code starts to look like a building of blocks, stacked on top of each other, and if one of them doesn’t fit, it can collapse in a second.

So what causes the generation of ancestral code?

The bottom line is that we don’t think about the responsibilities and capabilities of each functional module in a system from the top down.

The business (domain) drives design, which is DDD. It’s all about cohesion and decoupling, and that’s the core of what this little book will do for you.

🤔 why with “I” learn?

Looking at DDD materials on the web or open source projects on GitHub, you can either stack DDD basics like crazy or give you a Demo. A little bit better, a couple of diagrams or a Demo with a lot of notes, always missing a derivation.

It’s like your mother hitting you. She never makes sense. Now there is DDD, you just do what “I” do. But why? What’s the upside of this? … There is very little that is relevant.

  • The text of this volume is adoptedCompare ideasStart with the MVC three-tier architecture, or the development pattern we’re used to, and see what kind of problems there are. Then step by step, see how you can use DDD’s ideas of cohesion and decoupling to solve these problems.
  • Why do people know DDD when they have heard of it? That’s because concepts don’t correspond to actual code. Therefore, this volume will be presented after the systematic analysis and explanation of DDD concepts and theoriesActual Demo presentation, so that you can thoroughly grasp the core idea of DDD and landing operation.
  • What? MVC DDD migration cost too much, operation too troublesome? Don’t worry! DDD itself is a strategic idea in system architecture, and developing the system completely according to its specifications is only its tactical goal, we can completelySelect the good landing, good implementation of the part to optimize the system.

In short, after learning this small volume, it is difficult to level the “excrement mountain”, but there is no problem to dig it out.

🏆 What can you learn from this booklet?

Here is a mind map for this small volume of knowledge:

It can be seen that the overall setting of the small volume is like this:

  • Starting from the reasons for using DDD, the strategic thinking and tactical practice of DDD are explained step by step.
  • After the theory, I will explain how to build DDD project and how to practice DDD step by step.
  • Finally, I’ll walk you through how to move your system from MVC to DDD.

In short, do not stay at the theoretical level, but learn DDD systematically, understand it from the root, conquer it, and implement it.

🤗 Suitable audience for this booklet

  • Students who are interested in DDD but have not studied DDD systematically;
  • Students who expect to be involved or are currently involved in infrastructure development;
  • Students who suffer from the “shit mountain” of code but have no way to optimize, can only heap UP THE CRUD code;
  • A serious code cleaner.

We look forward to your joining us in the study of this booklet! From basic concepts to practical implementation, it takes you through the nightmare of top-down business-driven architecture, breaking old code and complex business maintenance difficulties.

🛒 How can I purchase this booklet?

Early bird discount limited time 50% off, only ￥14.95, 👇 click the picture below or scan the poster QR code 👇, join the learning ~