Darius Jazayeri

I could see either Option 1 or 2 working. It does make sense to encapsulate the logic in one place, and hopefully avoid code duplication, as is done in Option 2. But if this code will only be calle...

I could see either Option 1 or 2 working. It does make sense to encapsulate the logic in one place, and hopefully avoid code duplication, as is done in Option 2. But if this code will only be called in one place (e.g. the controller) then option 1 doesn't actually duplicate.

(Anyway, as Chongsun suggests Option 2, that's fine.)

Regarding the "where to put business logic" question: if there is a piece of logic that makes meaningful sense as a unit, and can be given a meaningful name, then yes, put it in the domain object.

E.g. if you could have requisition.determineXandYbasedOnZ(), but please no "initiate2" method!

I think that an ERD is the wrong way to diagram the workflow. (It's the right thing to show the data model, but that's only a piece of things, given the (micro)service architecture approach.) My r...

I think that an ERD is the wrong way to diagram the workflow. (It's the right thing to show the data model, but that's only a piece of things, given the (micro)service architecture approach.)

My recommendation for that this kind of ticket:

1. Start with a higher-level diagram that shows the interactions between services in the workflow (this could be a UML communication diagram, or even just a text description of REST endpoints and who is calling them in what order). This diagram would just show the user interactions and calls between services, but not show the details of specific fields.

2. detail each (newly-introduced) REST representation that will be sent over the wire in those communications.

3. detail out any classes that will be introduce within a service, focusing on their public methods. (In most cases I do not think it is necessary to do an ERD at this point, because that's implied by the REST contract in #2. But occasionally it might be required for clarity of design.)

Basically, the REST contract is the primary piece of the design. The ERD that allows a service to produce that REST endpoint is an implementation detail.

Does this make sense?

So then the extension-example module would be responsible for scanning its own classes?

So then the extension-example module would be responsible for scanning its own classes?

I went through all the files, and made a few comments. At the architectural level, I think this is broadly correct. The one thing I would change (and I guess Josh can vote now vs later on this) is...

I went through all the files, and made a few comments.

At the architectural level, I think this is broadly correct. The one thing I would change (and I guess Josh can vote now vs later on this) is that we should also support having an extension point that takes a list of beans instead of just a single bean. This feels like an important eventual use case.

Is this correct? I wouldn't expect to need to know about concrete extensions at compile time.

Is this correct? I wouldn't expect to need to know about concrete extensions at compile time.

It's not obvious from peeking at this code where this file should live by default. (If it's documented in the readme or elsewhere, that's fine.)

It's not obvious from peeking at this code where this file should live by default. (If it's documented in the readme or elsewhere, that's fine.)

Out of curiosity, isn't this an unnecessarily-wide scan?

Out of curiosity, isn't this an unnecessarily-wide scan?

ExtensionException would imply server misconfiguration, so this should be a 5xx status. (BAD_REQUEST is not correct.)

ExtensionException would imply server misconfiguration, so this should be a 5xx status. (BAD_REQUEST is not correct.)

(Trivial) I would have called this method loadConfigurationFile().

(Trivial) I would have called this method loadConfigurationFile().

I think we also need to support an extension point that's a list of bean ids, and thus we should also have a method `getExtensionListByPointId(String)`

I think we also need to support an extension point that's a list of bean ids, and thus we should also have a method `getExtensionListByPointId(String)`