[Translation] orchard Architecture Design Model

[Callback]

[Question ]:
I am currently studying software architecture and layering, and have read many open-source. Net projects, including orchard CMS. I think orchard is a good design example.
As far as I know, a good architecture should be UI, service, repositories and entities should be separated in differentProgramCentralized. However, in orchard, I can see that services, repository, and entity related classes and interfaces are all under the same folder and naming control.
Is this an anti-pattern? Or is the design architecture correct?

 

[Answer ]:
First, the Assembly is not a necessary condition for splitting the architecture.

The answer to your question is no. To determine whether they are correct, it is really important that they are indeed isolated, rather than whether they should be in different programming sets. In addition, unlike most systems, the factors to consider when developing a scalable CMS are different. In an extensible CMS system, the correct separation method should be to decouple features that may be added or removed at any time in the future. However, in a common hierarchical system, layered decoupling is required to reduce the risk of mutual influence. What really should be compared should be a hierarchical system and a module in orchard, rather than comparing it with the whole orchard. Of course, as implemented by orchard, good practices are all used in the module.

Division by assembly is based on separation considerations, which are already biased towards technical aspects rather than architecture. You can think of an assembly as an inclusionCodeFor code reuse and dynamic links. However, it is not a way to implement layering. This is why they use modules for code reuse.

In addition, we consider the following aspects:A good architecture has a major purpose, that is, to make programs more affordable and cost-effective (and not to design an architecture that only they can understand as designed for the Aerospace system ). The second goal is to write out scalable and well-performing applications (although this is even more difficult to achieve because it can easily lead to premature optimization, which is the source of disaster for many software ).

For the first purpose, conceptual separation is very important, but it is not so important to separate specific methods.
The second goal is contrary to the idea of using an assembly for layering: orchard already has many assemblies before you add additional modules. These assemblies are never used without restrictions. In orchard, they need to be dynamically compiled, loaded, JIT translated, and run through memory. In terms of performance, you should generally reduce the number of assemblies to achieve performance optimization.

For today's orchard, if you want to divide orchard into different sets of programs, and then divide each module into these sets in sequence. Then you will need to divide the number of layers * The number of modules, and hundreds of assembly will need to be loaded at that time, obviously not good. In fact, we even considered dynamically compiling all the assembly into one assembly.