Question - Business Rules about eventuous HOT 4 CLOSED

Hmm, not exactly sure what it means, could you elaborate? What are business rules?

When I look at this https://github.com/MarimerLLC/csla/tree/main/Samples/CslaFastStart#adding-business-rules, I see some sort of constraints (like "required"). As CSLA doesn't really promote having a proper model, everything is about "DTOs" (I hate this name). If you have a model, you have value objects to encapsulate rules for the values and aggregates where you guard the invariants.

It's probably a good idea to improve the error handling, as now it's almost exclusively done by throwing exceptions. It is possible to produce error events, but you don't always want them to be persisted. Having an attribute for events that need to be ignored for persistence is something I thought about.

When it comes to contracts, there are good tools like FluentValidations to do it.

My answer here seems to be chaotic, I am trying to explain how I would implement the domain rules and clearly separate them from "the edge" rules (before handling the command). What I can say for sure is that CSLA examples show something that I would never do.

So, my question would be what exactly are we looking at? Any conceptual idea, pseudo-code example you have in mind?

from eventuous.

What I am looking for is a way to define a model and validation for the respected fields. For example, email address or postal code. Or an integer field that cannot be negative. Being able to define this in the model provides contracts that a UI developer can base validation on before he attempts to send to the API. I am familiar with FluentValidation, but that is generally done on the server side.
Here is the idea that I am trying to achieve. https://scalapb.github.io/docs/validation

from eventuous.

The link you posted points to proto file annotations for validations. Similarly, you can build a Web API with contracts annotated with [Required] etc attributes. I believe there are plenty of methods to convey those annotations to the UI using the OpenAPI spec handling, the server would ensure that the values received are correct, etc. It's all happening before anything in Eventuous is engaged, so it's not the concern of this library.

The only place where Eventuous might step over to that world is the new generated command API, but I'd still consider it "experimental".

To conclude, there are tools to make it work. You are looking at the contract level, and Eventuous is about the domain model and things around it. Essentially, its work starts in the application service, where you convert primitive types from the command to value object. Value objects would ensure that things like email and postal code are correct. It's not validation per se, it's part of the model, and it cannot be expressed in a generic way because each model is different.

from eventuous.

Agreed. You have done a fantastic job on Eventuous. As I am transitioning my career I am looking to get more involved in contributing to open source projects. I have great interest in contributing to yours.

from eventuous.