# Temporal for small-scale plugin architecture

**URL:** <https://community.temporal.io/t/temporal-for-small-scale-plugin-architecture/2978>\
**Category:** Community Support\
**Tags:** use-case-validation\
**Created:** [September 20, 2021, 7:09pm UTC](https://community.temporal.io/t/temporal-for-small-scale-plugin-architecture/2978 "2021-09-20T19:09:52Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![aschrijver](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/aschrijver/32/1331_2.png) [@aschrijver](https://community.temporal.io/u/aschrijver)\
**Post date:** [September 21, 2021, 6:15am UTC](https://community.temporal.io/t/temporal-for-small-scale-plugin-architecture/2978/3 "2021-09-21T06:15:17Z")

</div>

Thanks a lot for your quick response @maxim!

> [@maxim](#):
>
> It depends on the data. Temporal persists data that is related to the lifecycle of objects it manages. It is not built to store historical data for example.

Ah, that wasn’t obvious to me yet, and I’d have to look deeper into. I may still have to provide my own persistence layer then, both on the write- as well as on the read-side. OTOH _maybe_ if, say, I have a `UserAccount` domain aggregate that is controlled and accessed via an _actor-like_ Workflow in the Application layer, then this workflow could be active for as long as the user account exists?

- Domain layer has no dependencies (inversion of control), guarantee valid (domain) state, and invocations raise events.
- Application layer has business logic which are mostly Workflows, Child Workflows + Activities.
- Domain events and domain errors trigger Signals in the Application layer to the running workflows.
- (Maybe) There’s no need for Repository interfaces in Domain layer, and DB impls in Infra layer. Temporal persistence is used.

The above may make no sense, not work. Shows my noobness on the paradigm shift that Temporal seems to offer. A safe architecture design would be to have the ports & adapters, DDD, CQRS/ES as I intended, but having Temporal only provide Saga capability and handle some clearly long-running tasks.

> [@maxim](#):
>
> Use [query workflow](https://docs.temporal.io/docs/content/what-is-a-query/) feature of Temporal.

Yes, but the read-site of CQRS would offer denormalized views on the data. But I think you mean to say this is the way to get at workflow state for implementing the read-side, which then has its own way of dealing with persistence.

> [@maxim](#):
>
> We want to support extending Temporal without the need to fork the main repository. So we certainly going to support this option.

With imported / embedded I was referring to the [Production deployment](https://docs.temporal.io/docs/server/production-deployment) page stating _“The Temporal Server is a Go application which you can [import](https://docs.temporal.io/docs/server/options) or run as a binary.”_ and then in my Go code calling `s := temporal.NewServer()` to fully embed the server instead of having it separately deployed (e.g. via Docker, etc.). I was not referring to forking and extending, just invoke functionality as-is but have the server code fully encapsulated in my own application. Is that possible, or did I misinterpret?

---

_[View the full topic](https://community.temporal.io/t/temporal-for-small-scale-plugin-architecture/2978)._