We are organizing the code incorrectly!

Original: [ https://dzone.com/articles/we-are-structuring-code-wrongly?edition=704394]
Translation: Zhu Kunrong

It's time to stop organizing the code as taught you in the beginner's tutorial.
​

Now, you should capture domain knowledge in your working code and protect your context from being contaminated by other knowledge contexts. What do ProductRepository and BasketRepository have in common? not at all. They are dealing with different issues, so why put them together?
​

Product, ProductServie, ProductRepository are highly coupled; why not put them together? They are a whole-the code changes together, put together, and carefully packaged. The stricter the restriction on your access level, the less chance that unnecessary dependencies will cause the final code to become a pot of porridge.
​

We must resist the temptation to make everything public! That's why the code base becomes a bunch of interdependent objects. It is important to block your bag properly. The package should contain all domain-specific/context-specific classes and only provide a specific interface for other packages to access. Then, instead of writing unit tests for each public method of each class as before, but only focusing on the public interface of the component to write unit tests, covering all method logic. [Click here to see my article on effective testing]
​

A component with a single, well-defined purpose is easy to understand and read. The names of the components clearly state their purpose.
​

The most basic story is that if your architectural intent is clearly mapped to the code, you can make it easier to understand and maintain. Your code should reflect the architecture diagram you drew.
​

Consistency and coupling

Codes that change together should be put together. Code that serves a common goal should be put together. Consistency is a very simple concept, and I hope you understand this.
​

Coupling is the next important thing to learn. He is about how a component depends on or interacts with another component.
(img)
Generally speaking, we should focus on high cohesion and low coupling. Practice the single responsibility principle through high cohesion. Reverse control is achieved through a well-defined interface to achieve low coupling.
​

Low coupling means there are fewer internal interactions across components. It means that a component will not affect other components when it is changed or replaced.
​

When software is broken down into smaller components, these components will inevitably interact with other components, which requires clearly defined boundaries to ensure that the domain is not leaked. The final system can maintain consistent interaction but is independent of each other, with clear boundaries.
​

The most basic content of this story is that if we can effectively draw and implement boundaries during development, the system can be easier to understand and read.
​

Demo

I wrote a project that uses modularity principles to design and implement a single application by myself. [Click here to obtain]. I also recorded a video to illustrate the part of the project discussed in the article.
​
https://www.bilibili.com/video/BV1SF411b7Y9/?aid=294436687&cid=450227741&page=1
​

---

This article is from Zhu Kunrong's WeChat public account "malt bread, id "darkjune\_think"
Please specify if reprinted.

Communication Email: [e-mail]
Weibo: Zhu Kunrong
Developer/Science Fiction Enthusiast/Hardcore Host Player/Amateur Translator