Consider using the word "component" where you currently use "module"

[mtnygard]

In most of the SEI books about architecture, they make a nice distinction that "component" refers to a runtime entity that participates in the dynamic structure of the system. In contrast, "module" refers to a unit of source code that is part of the static structure of the system.

Obviously with the move toward microservices, we are getting closer to a one-to-one correspondence between modules and components. Still, since the ISA principles address primarily the runtime behavior, it would be nice to align the language with the SEI's definitions.

[ewolff]

Thanks a lot for the feedback!

While I do see your point, I am not sure whether we should change the terms. The term "module" shows clear alternative to microservices - classic modules. Also properties like decoupling, single responsible principle etc. can be reused to understand the features of a great split into modules. It seems to me that these ideas are often neglected with microservices.

However, I could imagine that the terms "component" as a unit of deployment and "module" as a unit of development and the one-to-one correspondence could be a great way to explain the basic ideas. That could definitely be something worth investigating.

[aheusingfeld]

I totally get your argument to favor "component" as it is widely used - even by myself. The problem I see here is, I realized that people do attribute slightly different semantics, behaviour, and characteristics to "a component" depending on their background (e.g. frontend javascript developer, java backend developer, .NET developer, etc.).

On the other hand as Eberhard pointed out, I actually like the implied characteristics the term "module" has in literature. But you are not the first to state they are not immediately obvious. Let's review the definition and check whether we need to be more explicit about the characteristics we want to see attributed to the systems.