Location>code7788 >text

The Best Path to Learning True DDD

Popularity：998 ℃/2024-08-26 20:06:38

This instrument follows on from the previousIs DDD the first principle of software engineering?", follow the public number (Old Shaw wants to be a foreign language big brother) for information:

  1. Latest Article Updates;

  2. DDD framework source code (.NET, Java dual platform);

  3. Add a group to chat and exchange modeling analysis and technology implementation;

  4. Video and live streaming on B-site.

Characteristics of Fake DDD

Before we begin, considering that there is currently a lot of information about DDD that is very voluminous and mixed, we need to have the ability to differentiate between the two to ensure that we are not misled. Those of you who have read this series of articles will have some sense of how we view DDD, and here we list what we consider to be the characteristics of a fake DDD for your reference:

  1. Pile on the abstract vocabulary and make it unclear to the

  2. Says DDD is only for advanced developers

  3. Says DDD is hard to land

  4. Says only complex projects are suitable

  5. You said you could only go by experience.

Suitable for people

First of all, we believe that "domain-driven design is a value", so the premise of understanding and being able to practice DDD is to recognize this value, in this case, it means that the first step is the starting point, there is no threshold, as long as you subjectively agree with it, so we believe that DDD is suitable for all roles related to the software engineering work to learn and practice. practice, including but not limited to:

  1. Current students looking for a career in the software field

  2. Software engineers at all levels

  3. product manager

First of all, software engineers have to understand DDD, there is no doubt about it, I have a vague feeling that the real DDD is the only positive solution to software engineering, a lot of back-end veteran drivers have been suffering from the problem of rapid corruption of the system code over time, and DDD is exactly the underlying logic to combat this corruption, is the first principle of software engineering.

For the student population, the cases I've contacted have proven that it is conversely easier for newcomers to the software field to understand and accept DDD. This is because much of the current mainstream software design guidance points in the opposite direction of DDD, and newcomers, because they have not been misled by this information, and are free of the shackles of preconceived notions, are naturally prone to accepting the more profitable ideas of software design.

Software engineers favorite product manager, most likely to understand some of the technical product manager, and if the concept of DDD have an understanding of the product manager, I believe that in the demand analysis, product design, model design can be easier to understand each other with engineers and build consensus, we must remember the previous article said "anthropomorphic modeling communication method You must remember the "anthropomorphic modeling communication method" mentioned in the previous article, which can play a great role here, making the consistency of "requirement-model" better guaranteed.

Learning Path

The diagram below shows an iteration of a learning loop, and I think the feasible points are as follows:

  1. Learning concepts, through a series of articles and videos, to build basic conceptual cognition

  2. Learn to practice and do code exercises using the DDD framework

  3. Doing validation, a coach guides and constant hands-on experience, iterating on perceptions and behaviors

academic concept

We think the concept of DDD is concrete and easy to understand and practice, and if you have read through the previous articles in this series, then you will certainly get a feel for it, theLao Xiao's path to domain-driven design", of which key conceptual ideas include, but are not limited to:

  • Domain-driven design is a value

  • DDD principle

  • Clear boundaries are the most important thing

  • Consistency is more important than correctness

  • DDD is the first principle of software engineering

  • The complexity of the system comes from the number of elements and the relationships between them

  • the law of conservation of complexity

  • Anthropomorphic modeling communication method

  • Don't reuse

  • The Universal Model of "Command-Event"

  • If writing code is awkward, the odds are that something is wrong with the modeling

academic practice

Learning practice, that is, constantly modeling design, code implementation, at present we have provided DDD tactical framework for Java, .NET ecosystem respectively, based on the tactical framework, and supporting engineering templates, expect to be able to help your team in the state of no technical burden to experience the advantages and benefits brought about by DDD, so as to enhance the team's knowledge of DDD:

Java：/netcorepal/cap4j

.NET: /netcorepal/netcorepal-cloud-framework

About Coach

First of all coaching is not necessary, but a good coach can greatly accelerate your knowledge and application of DDD, and the core role of coaching is:

  1. Guiding cognitive understanding

  2. Teaching Practical Methods

  3. Validation of learning outcomes

Then for a good coach, I think the key thing is:Ability to determine if decisions (requirements analysis, modeling and design, code implementation) are in line with theDDDhealthy attitude.. To do this, then the probability is that a good coach fulfills the following characteristics:

  1. Accurate understanding of DDD

  2. Successful experience with practice

Where to find a good coach? (Commercial break) There is one right in front of you, follow me, I am playing the role of a coach on the air, feel free to interact.

Video & Live Streaming:

/6733407

How to judge results

A very important part of the learning process is positive feedback on results. Regarding DDD learning, in my experience, although I can't give clear quantifiable indicators, the following points can help you to subjectively determine whether there is progress:

  1. Now have a sense of control over requirements and systems

  2. Requirements-model-code is getting more consistent

  3. Writing code feels silky smooth

  4. Significant improvement in code bug rate

ultimate

We welcome the exchange of practical experience to continuously improve developer happiness.

<Previous