Introduce more sophisticated examples about polysemycleanarchitecture HOT 2 CLOSED

Thanks for your answer!

from polysemycleanarchitecture.

Hi, thanks for your interest in my article!

You are right, the article is not a meant as a comprehensive introduction to Haskell, domain driven design, clean architecture and polysemy. I'm just trying to explain how an algebraic effect system like polysemy can be used to implement a close to ideal clean architecture. Of course I'm not covering all the nitty gritty details.

Regarding your questions:

1. Validation is typically done across several (if not all) layers:

• Directly in the front end you'll validate simple syntactic errors (e.g. date formats)
• In the domain layer you can to domain validation typically handled by smart constructors (as you suggest)
• in the use case layer you do complex cross-domain validation. That is on the use case layer you can interact with data from different independent bounded contexts (e.g. "Customer" and "Contract"). You can validate customer and contract data with smart constructors of their domains. But in order to validate if a contract fits to a customer you'll have to validate both entities in conjunction (and this typically also involves cross-cutting business logic).

2. It's totally possible to handle expensive queries in the DB and access those queries by providing dedicated effects (and their respective implementations).

That said, I can understand your unease, as my example is not a classic bottom-up design where you start with an ER model in the database and build the higher levels on top of that.

When designing the domain layer I tried to model the actual domain entities from a user perspective and tried to keep the model clean of any 'persistence artifacts' (like technical keys, foreign keys, finders, ORM hints, etc.) This kind of model fits nicely to key/values stores or document oriented databases.

Of course you might model your data more closely to a traditional entity/relationship based model which fits better to a relational DB.

3. The use case layer handles the state of the data model. Adding aditional interfaces on the outer layers is the natural approach in clean architecture (aka. Onion architecture). A few days ago I added a few lines of code that allow to run a warp based rest service as an effect. In the same way it would be possible to run additional interfaces as effects in parallel. See also:
   #2 (comment)

from polysemycleanarchitecture.