pauljamescleary / scala-pet-store

An implementation of the java pet store using FP techniques in scala

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Package structure

elcolto opened this issue · comments

Hi,
thanks for this project, it's really helpful to get to know typelevel libraries. I get the clue behind splitting domain and infrastructure package.
While the domain package has a feature based structure, the infrastructure stays to component/technology based structure. But why?
Thinking further to add more domains like order, customer, shop and so on. Is it useful to place these domains into packages like doobie or inmemory. In case of several data sinks (like Elasticsearch, or a HTTP-REST service) it would be necessary to place implementations into packages like elasticsearch or http/rest

Would it be more significant to apply a feature based structure to the infrastructure package?

Greets

Hello @elcolto 👋

The domain package should be implementation independent. Following DDD, it contains Services (gateways to the domain), Repositories (where to get and save data), Models which are your domain models (which in FP tend to have no logic just data). Also, all your business logic, validations, and invariants go in here.

For infrastructure, I think this is where code organization can be rather subjective. I personally prefer the existing package structure, but it is definitely not a mandate. The onion architecture implementations I have come across (very subjective and limited to my experience) follow the same structure as in the pet store, and it is the one I use in "real" projects.

The onion architecture is not opinionated on package structure afaik. The main driver of the onion architecture is to keep infrastructure concerns separate from your domain.

https://dzone.com/articles/onion-architecture-is-interesting

I am curious if there are tangible benefits in following a structure you recommended. For example, new emerging standards where it would be more idiomatic.

I think the package structure was pretty well documented in 17ac1ae.

https://github.com/pauljamescleary/scala-pet-store#onion-or-hexagonal-architecture

Closing now. Reopen if there's something more to explain or improve upon here.