Add a 60K foot overview of architecture styles as it relates to CSLA

[swegele]

I've used CSLA since 2004 right up to current day in small to enterprise code. Recently CSLA made good on it's original promise once again by easily allowing us to make a major UI change from .NET Framework WebForms to .Net 6 Blazor. Once we got over the BL having to change to accommodate DI in CSLA 6, the rest was easy and exclusively involved changing the UI layer.

Lately I've been learning more about "Clean Architecture", "MediatR" and "Vertical Slice Architecture". I'm honestly a bit turned off by CA, but very intrigued by MediatR and VSA. Given the CSLA 8 e-book series coming out, I wonder about either a section there, or a couple blog articles, or even better a few video interviews where you compare these big-picture architecture styles and talk about IF and/or WHERE CSLA might or might not be used in those styles versus traditional N-Tier layered architecture.

For instance:

• They all seem to have a "domain" block on their diagrams but not many good real-world talks on what those are. What does it mean when they say "push your logic down (to the domain)"
• Is a MediatR Validator and it's Handler a competitor with a CSLA business object and it's business rules?
• If one was using VSA - would they still use CSLA?
• What parts of CSLA go with which layer/concern in each architectural system (e.g. 2-way databinding is pretty cool but requires the object to be in the UI layer).

In summary it would be cool to hear if you see CSLA as applicable only to NTier layered architecture or if it solves problems in other styles as well.

[Chicagoan2016]

I really don't know about Media R architecture : ) and the very little I have read about VSA, I don't think Csla would be a good fit.
If each vertical sliced could be implemented differently, that kind of goes against Csla-based architecture where business objects (and hence use cases) are implemented using known stereotypes, EditRoot, Read-only , command objects etc.
The dataaccess layer for each use case (or slice) could be implemented in various ways; stored procs, ORM etc. but I don't see any advantage to that approach.

[hurcane]

I think vertical slices and CSLA can play very well together. The idea of VSA is that each vertical slice uses the best technology option for its domain, and you don't force a rigid layered architecture on all domains within the project.

In a vertical slice design, CSLA is a great choice for any slice that requires complex business rules. If I'm developing a browser-based executive dashboard, I may not use CSLA at all for that slice. And because CSLA tries to be agnostic toward data and UI, the same CSLA classes can potentially be shared across slices, even if the UI and data technologies of the slices are different. A set of CSLA classes for customer orders could be used in a desktop UI with a three-layer architecture for internal customer service reps, but also used by an API with a single layer that is used by high-volume customers to submit their own orders.

Like any architectural decision, there are tradeoffs. One tradeoff of vertical slices is that it increases the complexity of the project with respect to training and deployment.

[rockfordlhotka]

Timely

https://jeremydmiller.com/2024/02/12/the-case-against-clean-architecture/

[Chicagoan2016]

@rockfordlhotka
How about the VSA?
When it comes to maintenance, I think it would be a nightmare for small teams : )

[swegele]

@rockfordlhotka You are right, that is a timely and salient interview related to my question (CSLA and CA and VSA).

Couple quotes:

You can keep your logical layers but still move to kind of a vertical slice architecture...this time let's organize kind of around the 'actions' in the system, the logical commands or events...organize more around use-cases.

Organize your code vertically first and then horizontally within that vertical slice.

Even modules within a closely related system, if you can upgrade one module at a time (he moves his hands in a vertical motion) that's much more efficient to be able to modernize overtime.

It seems like he is advocating the "mediator" pattern (plugging his own tool "wolverine" for implementing that pattern) because it's like MediatR-plus. Cool - I'll check it out.

We have a small efficient team so layered NTier works great for us. Yes full layer upgrades would be a pain! But we have great integration tests (as he mentions) since DEVOPS CI/CD makes it so easy to build up and tear down SQL so why not get great bang for buck with integration tests :-)

But I'm struggling to think how I would vertically slice our very mature and very complex enterprise product. I'm playing around with building a new project in a VSA style from scratch.

SUMMARY: He directly said what I sensed in my gut that you could still use CSLA in vertical slices. That lines up with what you have said Rocky about "behavior driven design". I just have trouble picturing it in practice.

I have questions like:

• what CSLA objects would be isolated to a slice
• what CSLA objects would be cross cutting
• where the CSLA objects live and travel (UI binding or in Domain layer called by MediatR handler) and whether they are overkill if the later
• whether MediatR validators have some overlap with CSLA business rules but is there need for both

[rockfordlhotka]

I've always suggested that good object-oriented design is use case specific - though I prefer the term "user scenario". If you step back a big, a user scenario is probably what folks are now calling a vertical slice. In that context, I have been, and continue to be, a strong advocate for OOD that is based around user scenarios with a de-emphasis on code reuse (outside of rules).

I guess more specifically, I always tell people that properties aren't "real code" and efforts to reuse property declarations is a road to long-term disaster. You can not have code reuse without coupling, and coupling is perhaps the ultimate enemy of all code maintainability. By extension, rampant or blind code reuse is also the enemy of code maintainability.

On the other hand, take a rule. Rules are generally quite discrete and well defined. They are the sort of thing one can unit test and built high confidence that the bit of code in question is reliable and meets business requirements. In CSLA a rule is a class, but realistically it is just a method - or you could say procedure. And the argument from decades ago (like 4-5 decades) was that procedures should be the building block of software. This is where we got FORTRAN and Pascal for example.

The problem people had back then was the desire to reuse procedures - which was done by adding more and more parameters with complex switch or if..else blocks in the code. Basically taking a procedure and making it into a massive state machine that should have been different procedures - but everyone was so focused on code reuse and "coupling" wasn't a term yet.

I suppose that's a risk with rules too - but the way the CSLA rules engine works tends to drive folks away from building a rule that is actually many different rules separated by switch or if..else blocks within the rule.

What I'm getting at, is that designing domain classes for a specific user scenario (often right alongside the process of doing storyboards for the UI supporting the scenario) should result in a set of domain classes that clearly automate the needs of the user scenario. The properties of those domain types almost certainly have some rules - and some of those rules may cross user scenarios (like postal code validation, or calculating a tax). And this is where CSLA provides the rules engine to enable somewhat loose coupling between the reused rules and the properties to which those rules are attached.

[rockfordlhotka]

I'm not an expert on Clean Architecture. I tend to steer clear of Uncle Bob due to factors outside the realm of technology, and that might be part of why I've never spent a lot of time learning about it.

My understanding though, at a high level, is that it is an onion model, with layers wrapping other layers.

I've never characterized the CSLA architecture (the "A" originally stood for Architecture) with that sort of visual, instead presenting it more like a layer cake (yummy!).

• Interface
• Interface control
• Business logic
• Data access
• Data storage

Either way though, it seems like the idea of well defined layers is key, as is separation of concerns, and the hard part: keeping concerns from leaking across layer boundaries.

The really hard part, with MIcrosoft tech since 1991 anyway, has been keeping business logic out of the interface/interface control layers (out of the UI). It is so damned easy to just put validation and other logic in the UI - and some UI frameworks have encouraged it directly (XAML for example).

The result is that (to this day) most apps are built with tons of logic in lost focus events, button click events, in controller postback methods, and other places where business logic absolutely must not exist.

It seems to me that Clean Architecture, like CSLA, is based around the idea that violating this rule (like almost everyone does) is why it is effectively impossible for apps to survive a UI tech change.

Nearly every enterprise out there is stuck maintaining Windows Forms and Web Forms apps, because the business logic is hopelessly interwined with the UI layers (and sometimes even the data access is intertwined - though obsoleting the DataSet helped!).

Yeah, see, now y'all have me ranting 😁

[swegele]

I'll reply to both your comments here...

now y'all have me ranting 😁

Don't stop...I pick up gems when you rant (at least about technology - UPS package tracking not so much 😁 ).

I always tell people that properties aren't "real code" and efforts to reuse property declarations is a road to long-term disaster

Vigorously nodding my head. My first go at CSLA back in 2004-5 was just such a disaster because I was trying to re-use properties. Ugh it was horrible. CodeSmith and then T4 templates to the rescue but it still makes me flinch to have so much repetitive property text.

...user scenarios with a de-emphasis on code reuse

Our business layer is cleanly isolated from other layers and our team is pretty good about maintaining that separation. To your point, this made our recent translation from WebForms to Blazor a real breeze (another win according to big original reason for CSLA)
BUT...I admit the BL is super-coupled inside itself (crossing user scenarios). This is most prominently seen in read only objects being re-used all over the place - like beefed up DTOs with some minimal security added here and there. I see that writeable CSLA objects lend themselves more to focused vertical slices even if that means repetitive chunks of code (mostly properties)

One thing I see a lot of in the VSA and MediatR demo's is stupid POCOs / DTOs being the data thing passed around between the layers and being validated before the Handler. Obviously those work well for feeding in/out of a WebAPI. I find myself thinking about where CSLA objects fit if the UI also gets it's data in the form of JSON POCO from a WebAPI? Maybe a CSLA object ingests that POCO to light itself up and work on behalf of that particular UI user scenario?

[rockfordlhotka]

Now you've touched on (at least) two of the primary ways people think about rules engines: pipelines/workflows and interactive domain types.

Of these two, most (all?) commercial products follow the pipeline/workflow approach, where you feed in a set of data (POCO or whatever), the pipeline rules rules, and you get back a set of potentially altered data along with a list of what was wrong with the input. Very good for non-interactive scenarios like batch processing, web postbacks in old-style web models, and mainframes.

More rare is the CSLA approach of an interactive domain object graph that immediately runs rules as the graph is changed (properties, add/remove instances, etc.). This approach isn't as good for batch processing or web postbacks, and didn't exist when mainframes ruled the world. But it is really good if you are building an interactive user experience and want to keep business logic out of the UI layers.

[swegele]

OK that makes sense...and explains why nearly all the demo projects and youtube vids out there show POCOs flying around being validated by the pipeline.

My current solution has many VERY rich/interactive/complex screens so it's been a great fit for CSLA especially now with blazor server side and the return to rich 2-way binding and edit forms. It feels like "We're baaaack!"

On a new solution I'm playing with, I'll be using Cosmos NoSQL so POCOs are good. There will be far less and simpler screens. I will try out VSA, MediatR and keep an eye out for a scenario where a CSLA object could meet a need in a slice. Will be fun.

[Chicagoan2016]

@swegele You mentioned moving from Webforms to Blazor. We have a couple of Webforms applications. Which flavor of Blazor did you folks pick?
Thanks

[swegele]

We picked Blazor Server for our LOB app:

• our users (at office and remote) have decent low-latency connections so they have a similar experience as if they were using remote desktop
• our user's do not work "offline"
• dev experience is super productive (similar to winforms stateful dev - see note about routing below)
• pages have quick/easy access to server resources (drives/network/etc)
• we didn't want proprietary code in browser that can be de-compiled)
• we don't care about deep linking for search engines (there is no public access)
• we don't have to worry about the back button because we never keep history past the login page so if the user hits browser back button they end up logged off and looking at the login page which trains them quickly to use our page nav instead :-)
• because of the WebSocket connection is isolated per tab - we get the ability for one user to login via multiple tabs (oh let me do this other thing real quick by logging in as admin in this other tab) AND we get the ability for multiple users to login (trainer / trainee).

Couple special things we do:

1. Less routing favoring the benefits of stateful dev - Root pages (routed to) can show their content OR they can show child page content (List Page -> Add/Edit Page). Even Child Pages can show child content (Sub Detail Page). Typically we route from page to page...but when you route in Blazor you have to stick your objects somewhere and fetch them by ID later which is a pain. We have each blazor page either show it's own main/default content OR a DynamicComponent. Example: if you are seeing an Add Project page, chances are behind the scenes you are actually on the Project List page which loaded the Add Project page. This is very easy to use and understand for a new developer. If the need arises, we can route directly to the Add Project page because it is smart enough to know if it was loaded by a parent page (parameters populated) or if it was routed to directly (looks for it's data in a session store). Child pages can easily notify parent pages via Actions or EventCallbacks or skip that if .HasDelegate = false

2. Implement a Root Window per user with potential multiple Child Windows still associated with that user. Think about a user logging in looking at Project A and then wanting to compare that with Project B in a separate tab. (think MDI back in the day). The system is smart enough to know "Hey you already have that open" or "Hey before you logoff you should save your work in the 2 child windows you have open".

[rockfordlhotka]

With regard to MediatR, I've used the library/package as a way to manage some messaging but didn't realize there was an entire application architecture behind it. I look forward to learning what people think about using it for more than a loosely coupled messaging tool.

[rockfordlhotka]

Also, since I was ranting anyway, I did a mastodon thread:

https://elk.zone/fosstodon.org/@rockylhotka/111925831104217117

[Chicagoan2016]

Thank you for pointing this out, I am guilty of making the same 'mistake' : )

I guess more specifically, I always tell people that properties aren't "real code" and efforts to reuse property declarations is a road to long-term disaster. You can not have code reuse without coupling, and coupling is perhaps the ultimate enemy of all code maintainability. By extension, rampant or blind code reuse is also the enemy of code maintainability

It also reminds me of the time when I first started working with CSLA, I couldn't figure out a way to implement Inheritance in Csla and by that I mean base classes (abstract and concrete) with derived classes having its own 'Data Portal' methods.

[swegele]

I keep thinking about how a solution might have BOTH a WebAPI and a rich interactive LOB app. For the LOB app, I would want direct access to the richness of CSLA business objects. But for the WebAPI I will be feeding DTO/POCOs to N number of unknown client UIs/processes.

So MediatR "could" be used for both behaviors:

1. The WebAPI -> MediatR -> DTOs
2. Rich LOB app -> biz objects

Number 2 is pretty straightforward so I won't talk about that much (other than to say organizing into vertical slices makes it so that you don't care whether you've coupled your app with CSLA objects because pages are isolated in slices). Your LOB cuts out the middle man (JSON and DTOs). I think the LOB app could use MediatR to abstract away the details of fetching biz objects but I'm not sure it helps there since you'd be coupled anyway. I keep thinking parts of MediatR might compete with CSLA features but I don't know till I try it out to see if there is overlap and whether it is useful or not. Don't want to use a technology just because it's sitting there.

Number 1 is more interesting. The WebAPI would use MediatR to pass along requests (for the meaty stuff). It would not know that the MediatR Handler is using the same CSLA biz objects as LOB app to get the job done. The CSLA biz objects would be made to know how to validate/consume/produce data from/to DTOs....like hydrating themselves from DTOs and validating their state prior to continuing on.

[rockfordlhotka]

The only thing that occurs to me, is that if you don't build your UI directly on the CSLA domain types, then you lose all the data binding, rules binding, and other productivity features provided by CSLA.

[swegele]

😁 A new term I keep hearing "modular monolith"

I'm not sure why but that makes me chuckle.

[rockfordlhotka]

Another take on the overall topic.

https://thenewstack.io/composable-architectures-vs-microservices-which-is-best/

[swegele]

I can definitely see the need for and benefit of "composable"! I've spent weeks setting up a cloud native solution trying to incorporate the latest stuff. Here is my stack so far:

• .NET Aspire
• .NET 8 Minimal API
• Swagger (with oAuth2 enabled in its UI)
• Microsoft Entra for Customers (eventual replacement for B2C) with WebAPI auth using OpenId / Oauth2
• Cosmos NoSQL with RBAC
• DefaultAzureCredential (gets rid of secrets and api keys in code)
• Vertical Slice Architecture
• MediatR
• Returning ErrorOr from MediatR requests
• MediatR pipeline handler for validating requests
• FluentValidation for MediatR validators
• MediatR pipeline handler for Exceptions in requests
• .NET 8 global exception handler - IExceptionHandler
• ErrorOr -> ProblemDetails for non-happy path results
• and more...

Sheesh...ok yeah it's great to have a modern foundation to build upon...but dang it takes a long time yet I still don't have any business logic written. When can I start building an actual product?

P.S. @rockfordlhotka @TheCakeMonster - the ErrorOr nuget package strikes me as a potential tool we could use for the projected changes to DataPortal results.

[swegele]

Other than ErrorOr - this is a very popular library that I'm just now clueing into :-)

https://github.com/altmann/FluentResults