I've been experimenting with layered, use-case-centric architectures as described in Uncle Bob's Clean Architecture blog post. Most of the examples I've seen are simple "update the customer record" use cases, which make sense. Where I get a little lost is when it comes to creating objects.

To make things a little more concrete, suppose we have two use cases (which we model as interactors):


Now, most of the things operations do would be interactors in this design (rather than operation object methods), but operations remain first class objects in their own right. For instance, operations might need to carry bits of state like a globally unique identifier, a log file, or a list of observers. So it seems like the begin_operation interactor should create some sort of operation entity and the end_operation interactor should dispose of it.

The question is then, how do we manage the creation of these objects? How do we communicate information about them to interactor clients?

I've thought of a couple of possible approaches:

  1. Just create a new operation object and pass back a pointer to it (possibly in some sort of obfuscated form).
  2. Store operations in a operation repository of some kind and pass back a look-up key. This isn't entirely different from (1), but at least I could detect when I'm passed an invalid operation handle.

Neither approach seems great to me. What's the best way to handle this?

  • 1
    Those aren't use cases; they're implementation details. I think you're going to have to explain your terms a bit better. Is there such a thing as a "Use Case-Based Architecture?" Every program has use cases. You would manage object lifetimes in a "use case based architecture" the same way you would in any other architecture. Commented Dec 15, 2016 at 15:32
  • Reading the link would clarify what I mean. TL;DR: in a use case-centric architecture, the use cases themselves are first class objects. You could think of it as a variation of the command pattern. I'll edit the post to try and make it a little more clear. Commented Dec 15, 2016 at 15:40
  • Your two implementation details: begin_operation and end-operation form a transaction. I would start there, by studying transactions and Units of Work. There isn't anything in that Clean Architecture blog entry that would convince me that transactions would be treated any differently than they would in any other architecture. Commented Dec 15, 2016 at 15:56
  • I think you're getting too hung up on the example--I'm just trying to avoid extraneous details here. The fundamental problem is that I have an interactor that creates an entity that outlives the interactor invocation. The questions are: (1) how identify the entity to callers, and (2) how do I manage its lifetime? Commented Dec 15, 2016 at 16:02
  • Why does the entity outlive the interactor invocation? Why is that important? Commented Dec 15, 2016 at 16:04


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.