software modules and Domain concepts

Technically we often emphasize modularity, component, but can really achieve the software modularity, need to have a certain degree of understanding in the business area to achieve.

We may have specialized training modules and module technology courses (OSGI, etc.), but such courses do not tell us how the specific situation in the field should be divided into modules, presumably the ability to identify and divide modules is taken for granted. But that is not the case in fact.

Use an example to illustrate: If a website needs to add an ad function. There are probably the following possibilities:

• If the site is not modular, go directly to the code to make changes. And the consequences will be that the code gets bigger.
• If the site has been divided into different modules, we will see if the new functionality belongs to which module has been defined, and then the new code will be added in this module
• If the new feature does not belong to any of the previously defined modules, we will create a new module.

The key of the last two points is how to define [belongs].

Does the new ad feature [belong to] part of content management (CMS)? After all, the ads will also have content features (text, pictures, hyperlinks, etc.).

Advertising function can also be a module, because the click-through rate of the ads directly affect the site's revenue, and the site content is not the same as the nature of the processing results may be different.

In addition, it is possible that advertising functions are within the jurisdiction of the marketing department, and the effect of advertising may be accounted for by the business department and the Finance department after analysis. From the business flow we can also think that this advertising function belongs to the marketing department of a system function.

In Eric Evans's domain driven design, the importance of domain designs was advocated, with bounded context referring to model boundary issues. And Sam Newman in the building MicroServices book also mentioned that micro-services are best also based on the bounded context to divide.

Usually I do the module partitioning according to the following relationship:

• Owners and users of domain objects
• Analysis according to the natural boundary (department) of the Enterprise
• Is there a virtual abstraction relationship that associates two seemingly unrelated realms, and this virtual abstraction may be a shared high-dimensional module?

There are also two important technical concepts that need to be involved in the analysis: low coupling, high consistency

• Low coupling = Changing the code of a module without causing the need to modify the code of other modules that depend on the module
• High consistency = objects of the same domain, as far as possible together and published together

There is also a simple check, that is, by thinking in a position, stand in a field of perspective, to determine what the domain vocabulary should be in what module appears, and should not be in what module.

software modules and Domain concepts