Taxonomy and Categorization Refinement

[xJREB]

Some suggestions to refine the taxonomy/categorization. Please provide your views, if you don't agree.

• Rename dependency to coupling, as it is a common service-oriented term and matches nicely with cohesion
• Does it make sense to keep categories with only one antipattern? Remove many_methods, multilayer, management, and standardization. Maybe you find ways to generalize existing categories to include the antipatterns covering the deleted categories. You could also think about merging standardization and management. Lastly, not every antipattern needs a tag I guess. As many tags as necessary, as few tags as possible. 🙃
• Is the system tag really necessary? It sounds rather general and the architecture category may be enough. The only difference is the antipattern Overstandardized SOA that could probably also be assigned to architecture instead of application. But I haven't read the definitions for the categories yet... 😋
• For the switch between SOA and Microservices, Context may not be so fitting, as it would be overloaded with your JSON attribute. Maybe Architectural Style or Paradigm would be better? Moreover, 33 of the 37 antipatterns seem to be categorized with SOA. Are there really that many antipatterns that are valid both for SOA and Microservices? For example, Duplicated Service or Redundant PortTypes may not be antipatterns in Microservices, because there, you often take a conscious decision to duplicate stuff instead of creating coupling through reuse and generalization.

[boceckts]

We reviewed the antipatterns but in our opinion the microservice and soa tags are placed correctly. Any additional thoughts @mpoqq @tschechlovdev

[xJREB]

OK, while refining the JSON files, I also thought that most tags are placed correctly for SOA and Microservices. The only thing I've changed in this regard in #125 is the removal of microservices for the antipatterns Duplicated Service and Redundant PortTypes. I was also tempted to do the same for Extraneous Adjacent Connector, but refrained from doing it for now... Duplication is often a conscious decision with Microservices, because it reduces coupling and increases service and team independence.

[xJREB]

Addressed in #125