0

I have an ERP-style system that needs to allow users to orchestrate an Entity.action() on a variety of objects that implement the Entity interface, at different datetimes. Calling action() would change the Entity state.

What design pattern/architecture would be appropriate to allow users to store and manipulate a logical grouping of actions at various datetimes, maintaining a good level of abstraction so that it works on the Entity interface?

The Entities are all in a low-bandwidth IOT network (therefore open-loop control); there's no real-time control feedback and they update their own internal calendars via occasional downlink. Telemetry data would be stored and referenced separately.

Escher
  • 185
  • 1
  • 7
  • I'm afraid terms such as 'orchestrate' are too vague to understand what your use cases are. It's also unclear why ERP users would care about the underlying objects and methods -- I'd expect those users to care about rules and operations related to the business, not implementation detail. I'd suggest taking a step back from the implementation and focus on your UX and user journeys to define the business requirements for the ERP system and what your different kinds of business users will see on their screen, how they will interact with it, and what use cases they will be able to work with. – Ben Cottrell Sep 25 '22 at 13:24
  • @BenCottrell "orchestrate" means "schedule multiple actions, respecting timing between them". One of the most valuable parts of ERPs is their general functionality can be specifically adapted to a user's business - the objects and methods are what causes the software to "make sense" to users, because it models their business. Imagine it like an ERP for [Andy Grove's breakfast factory](https://beaugordon.medium.com/high-output-management-by-andy-grove-key-takeaways-af7c22a2d30d), but adaptable to making other meals in the future. Is there a design pattern to schedule those activites? – Escher Sep 25 '22 at 17:55
  • @Escher The point is that users would typically have an already-configured, customised system which already has the adaptation in-place and just allows them to do their job, What you're describing sounds like the implementation detail of the system, and something for developers to handle (e.g. using a programming language, or perhaps by creating/editing configuration entries tied to features of the system) when they're creating or modifying the underlying scripts and configuration which defines those rules. – Ben Cottrell Sep 26 '22 at 06:29
  • I think the thing which is still missing are the use-cases from your users' point of view, and then analysis into those use-cases; i.e. focus on what an already-configured system would look like and what the customisations would actually do then work back from there, otherwise you're looking at something entirely open-ended and where all possible approaches are equally 'right'. – Ben Cottrell Sep 26 '22 at 06:38

0 Answers0