What is the difference between "Separation of concerns" and "Modularity"?

Question

I'm studying for an exam and one of the questions, is about the concepts Separation of concerns and Modularity. But I struggle to see the difference between the two concepts, since both of them seem to be about reducing complexity in data by dividing it into smaller parts/modules? So is there a way where these two concepts differs, or are they just very alike?

Answer 1

"Separation of Concerns" encompasses:

• Modularity
• Cross Cutting Concerns

I would say that Modularity is creating modules that contain similar functionality. There is also an implication that similar functionality is moved into the module, i.e. you don't have two modules doing the same thing.

Cross cutting concerns are a bit different, typical examples might be: connection pooling, transaction management, logging, recording metrics, ...

Often CCC have a centralized component (setting up the list of log files) and a distributed part (actually generating log messages). Although the CCC code is distributed throughout your application (many "modules" require logging and transactions) the distributed code is fairly standardized: an @Transactional annotation or logger.warn(...) call.

Answer 2

The concepts of 'modularity' and 'separation of concerns' are distinct concepts that are highly related. That is, you can have modularity without separating concerns and you can have separate of concerns without modularity. I think your question is perfectly understandable because the two are generally used together in well-designed software. The use of modularity to implement separation of concerns is so common that wikipedia page for modularity says:

that emphasizes separating the functionality of a program into independent, interchangeable modules

At first glance we see 'separating the functionality' which sounds a lot like 'separating concerns' but there's a subtle distinction between 'concerns' and 'functionality'. The crucial aspect of modularity is concept of 'interchangeability'. If you can replace one component of your design with another component without changing anything else, we can say there is a high degree of modularity with that aspect of the design.

A really common reason to make components modular is to achieve a separation of concerns. For example, if a design needs to support multiple approaches to persisting data, a proven approach to doing that is to separate the concern of data persistence into interchangeable modules.

A logical question to ask is, when would you use one without the other? Separation of concerns without modularity is pretty common. But honestly, I'm struggling to think of a good real-world situation where it would make sense to modularize without separating concerns. Perhaps someone will be kind enough to propose one in the comments.

Going back to the example of data persistence, it's often the case that you don't have a requirement to persist data in different ways. You just need to write to a specific flavor of database. Interchangeability isn't (strictly) needed in that case but it's still typical (and good practice IMO) to keep the details of persistence isolated from the 'business logic' of the rest of the code. That doesn't mean your persistence logic interchangeable, however. There are additional design elements needed to introduce modularity. Separating concerns will tend to make modularization easier, however.