0

Imagine having the entity Counter and a use case that creates it. Moreover the business logic requires that every time a counter gets created a background task that increases the counter every 1s must be started too, should terms like "scheduling" appear in a use case?

class Counter{constructor(public id: String, public count: number) {}}

interface CounterIncreaseScheduler { schedule(counterID: string): void }

class CreateCounterUseCase { constructor(private counterIncreaseScheduler: CounterIncreaseScheduler) {} execute(counterID: string) { // create counter // persist counter this.counterIncreaseScheduler.schedule(counterID) } }

class NaiveCounterIncreaseSchedulerIMpl implements CounterIncreaseScheduler { schedule(counterID: string): void { setInterval(() => { // call increase counter use case }, 1000) } }

Also, is it idiomatic to spawn an input adapter from an output adapter? As in the example above, the output adapter CounterIncreaseScheduler would need to spawn a background task that would become an input adapter that increments the counter through another use case. What about implementing some sort of polling/pubsub? Is it up to developer decision?

rockson
  • 43
  • A "User" can be a person or a system. Does that answer your first question? – Robert Harvey Mar 15 '21 at 19:46
  • is it idiomatic to spawn an input adapter from an output adapter? -- Generally no; I think that would be an SRP violation. – Robert Harvey Mar 15 '21 at 19:48
  • @RobertHarvey Sorry my first question is if terms like "schedule"(or maybe even "broadcastEvent") may appear in a use case. Maybe I'm missing your point. So anyway if I can't spawn an input adapter from an output one, what else can I do? Implement a polling system that listen for new counters? – rockson Mar 15 '21 at 19:53
  • 1
    My point is that a system can be a participant in Use Cases. Any other word that you deem suitable from that perspective should be allowed. – Robert Harvey Mar 15 '21 at 19:54
  • Oh I see, got it – rockson Mar 15 '21 at 19:56
  • As to the output adapter spawning an input adapter, nothing prevents you from doing that, but I don't think you can call it an output adapter anymore. – Robert Harvey Mar 15 '21 at 19:56
  • Yeah I see your point but if not that then i would need to broadcast an event in a use case and then listen for that event to actually spawn the background task. That shouldn't violate SRP right – rockson Mar 15 '21 at 20:08
  • You would have to make the determination as to which approach is better for your specific situation. – Robert Harvey Mar 15 '21 at 20:12

0 Answers0