Ent: Question: ent and DDD (domain driven design)

[metalrex100]

Hey there, thanks for your work on ent-framework.
I have a question about possibility to use ENT only as a tool for dealing with infrastructure layer (database).

According to DDD application layers should be decoupled. It means that domain model and database schema are 2 different things and should be separated.

Is it possible in your opinion to use ent entities only for interaction with database and then transforming ent entities to domain models? What problems do you see (may be already faced) with such approach?

Or ent entities were designed to be used across whole application/micro-service also as domain model?

Thank you.

[a8m]

Hey @metalrex100! Sorry for not responding your Reddit message, I just saw it.

Is it possible in your opinion to use ent entities only for interaction with database and then transforming ent entities to domain models? What problems do you see (may be already faced) with such approach?

I'm not really familiar with DDD, but I can give 2 examples of what we do in such cases internally:

1. We have one service that exposes a GraphQL API, where some of its GraphQL types (or partials of them) exist also in ent. In this case, we use the autobind option in gqlgen to do the mapping between the database objects to the API objects. Of course, our GraphQL schema contains types that don't exist in ent schema, and vice-versa.

2. Another service, use Swagger (specifically, go-swagger). In this case, we use 2 different objects for type T. For example, an ent.User and a models.User (Swagger model), and we use external-templates in ent to auto-translate the ent object to Swagger object.

Of course, there are more cases. If you can elaborate on your use case, it will help me to get more context.

[metalrex100]

@a8m thank you for you response.
I got the idea about GraphQL API. I also use gqlgen and it’s nice to hear that it is possible to integrate ent with it since both gql and ent are about graphs. (Is there any docs/tips how to do it? May be I didn’t see such section in docs)

About layers architecture: when you isolate your business logic models (and services) from infrastructure specific stuff (like some database (or specific ORM) or some email provider), your application’s business logic become independent and flexible and does not depend on implementation details.

For example I have User model (structure). And I need to save it to some storage. I can create UserSaver (business logic layer) service which will have UserRepository service (infrastructure layer).
The thing is that all services which need to save some user will use UserSaver service. Business logic services don’t need to know details about database or other storage specifics.
And UserSaver service will have UserRepository service which will handle saving users to database (or other storage) and fetching them.

The benefit is that if someday I will realize that ent framework is not maintained anymore, I will need only to rewrite UserRepository service. My business logic services will still work ok, because they don’t know about details and independent from ent.

But as far as I understood ent framework designed in the way when your whole application should use ent models (entities). And if some day I will need to replace ent by another orm, I will have to rewrite the entire application.

The main idea in dependency inversion. Business logic stuff is not affected by infrastructure changes.

[a8m]

Thanks for the explanation @metalrex100.

I got the idea about GraphQL API. I also use gqlgen and it’s nice to hear that it is possible to integrate ent with it since both gql and ent are about graphs. (Is there any docs/tips how to do it? May be I didn’t see such section in docs)

There's no available doc at the moment for this integration - I'm actually working on it.

About the 2nd part of the comment - tbh, if you aim to go with this approach, you'll lose many of the stuff that ent provides. For example, one of the main benefits for using ent schema, is that ~all logic regarding your types reside in one place - which is the ent schema. You can define constraints or validators on fields and types, and even with the upcoming privacy later, you will be able to control who can query or mutate each type (or an edge). The GraphQL integration will also be part of schema.

[metalrex100]

@a8m I see. It means that applications which use ent
actually will be “ent-based applications”.
Probably it’s a good approach for such cases as gql api server.

Thank you for explanation!

[a8m]

Closing, but feel free to continue the discussion if you want. Thanks!