Chapter 4: Consider adding topic of API sizing

[kuromogeko]

Hi,
I think chapter 4 would benefit from drivers and heuristics used when "sizing" an API.
An experience I often had when reviewing APIs was that the "sizing" was not well done. APIs tried to serve too many use cases at once or had 20 different stakeholders (which all had to coordinate their changes). I think adding an LG would help the curriculum as LG 4-1 explains any potential issues and naming heuristics for preventing them gives participants a better chance to prevent "gigantic unmaintainable APIs" from happening.

Top of my head the following heuristics might be of interest. You probably know a lot more

• One Consumergroup/ Stakeholder per API
• Singular business process
• DDD: No API spanning several bounded contexts
• Only one represenation for each resource

(All of them sharing the motivation "single reason for change".)

Drivers might be

• An mvp size to create a marketable product
• A set of features encompassing a use case
• Predefined Team sizes or intention or parallel development
• ...

[dret]

@programming-wolf, as much as I agree that this is a useful discussion to have in the training, do you think that's relevant enough to become part of the learning goals and the curriculum?

[programming-wolf]

It's basically what you learn in foundation level: separation of concerns, interface segregation principle, etc.

It should be discussed in the training, as it is (un)common sense to design APIs properly and according to their use case, but I personally would not add it as a separate learning goal.

But: neither am I an expert, nor do I have any stakes in this curriculum.

If this occurs in multiple trainings that this concept is new to participants, we can still consider to add it in a .x release.