How do I encapsulate domain logic and preserve state in DDD+Clean Architecture

Question

(For context I am developing in Angular)

Historically my applications have tended towards the layered architecture that the Angular fraemwork leads you into.

However I feel that the next application I write will benefit from leaning into Clean Architecture and DDD.

I have read extensively on the patterns and am preparing for my first real-world excursion into this architecture. However I am stuck on what seems a very simple detail.

Domain

For simplictity the domain I am working with has an entity called Account. The Account has a method called setVIP which updates a number of properties within the account. My initial intention was to model this as a Class with public methods and private data

UI

I have a single view that displays the account and allows a number of actions against it e.g. 'set VIP'. There is a Save button which persists any changes made to the API via a single update call

Application

Will contain a facade to retrieve and update the Account

Repository

The concrete implementation of my service class called by my facades

I will use interfaces to invert dependencies as per Clean Architecture.

My problems is very simple.

1. If I use an object of type Account as the request/response between Application and UI, the UI will be able to directly call the setVIP method on the Account object (which likely returns a new Account object for immutibility). My view will contain an Account object and my view populated directly from it. However passing domain objects around is not recommended.

2. Alternatively I can call a facade method to setVIP which in turn would call setVIP on the class. However, it would either have to instantiate a new Account object at the start of the method or retrieve one from some state somewhere. After this it would likely return a DTO to the UI rather than the Domain Object

Option 2 would cause me to maintain state in my application layer and then translate it to and from a DTO, just to avoid using the domain object directly. What's the correct approach?

Apologies for such a noob question, but we've all got to start somewhere.

Thanks

Answer 1

The usual answer is that rather than trying to have the UI manipulating the domain objects, what you are doing is having the UI pass information "inward" toward the domain model.

For reference, see this diagram (taken from the clean coder blog):

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls.

You sometimes hear people talking about "messages" here. Same idea.

Boundaries, by Gary Bernhardt is a pretty good talk about these same ideas.

So your Option 2 is the closer of the two to the "clean" style. There's a bit more... ceremony...? motivated by the promise that the separation of concerns will lead to long term cost savings (because the code is easier to maintain).