Dealing with UI in a Domain Driven Design

[Sebastian Schabbach]

Dear all,

at the beginning my very sorry for all my mistakes I will make in dealing with content about that forum, but please considerate i am new at DDD and these is my first action here in the users group. I have heard something about DDD last month on a .NET Developer conference, and cause what I've heard was very useful for me, I began ordering the books from Martin Fowler and Eric Evans, and it's really fantastic. Even I am not completly gone through this stuff, I aim to write some software in this learing curve and I feel good with doing DDD with my application, nontheless I feel some experience is missing.

So let's come to my question: I read a lot out of the book written from Eric Evans about how to deal with the domain. There are Entities, Value objects, Aggregates and so on. So I feel well prepared to set up a domain model with myslef (sorry but I am the domain as well which is a little bit tricky to handle), but there is no idea for me how to handle things outside of the domain, for example requirements in the UI Layer. My application is working as a rich client application, with WPF as the UI Frontend and it also used the MVVM Pattern. I think it's a good approach, but as I learned that the Viewmodels, which are parts of the MVVM Pattern, must not deal with any models in the domain layer and the domain layer must be free of dependencies.

So doing that I decided just design viewmodels that holds data the UI can be bound to. Loading that data was not a problem due I introduced an application controller, which can consume repositories and infrastructure services to load data out of a datastore, which in my case is a relational database, but is encapsulated by the repository pattern. Everything works well as long as I had been working with a readonly application.

Now it's time that the user invokes some commands, that means the user want to do something in the application. The problem now is that because my viewmodel is absolutely seperated from the domain layer, there is no domain object the operation can work on. My idea now is to delegate that work to the application controller, that could be use a factory to create the appoxiate aggreagate and work on the aggregate root object to handle the user click. But that means, that everytime the user invoke some commands, he will work on a new domain object, isn't it?

I an absolutely unsure wheather it is the right way to do. Maybe I can get some help on that from the user group. It would be very greatful.

Kind regards,
Sebastian.

[Aryeh]

Hi Sebastian,

Welcome - everyone is new to one degree or another, so don't worry about mistakes! My wife tells me I make them constantly.

First a caveat, I would consider if DDD applies at all to your application. If a problem domain is trivial or non-complex, or if it is in the computer domain, you might be better off writing simple procedural code or another alternative.

My answer? Represent your element of human interaction (e.g. a window, report) as an object. Have it call a method on an object in your domain model. What, no 10+ tiers, frameworks, patterns and technologies? :)

DDD at heart is about representing a real-world system or problem as an object domain model, and then the representation of that model in working code.

There is no presumption that such a system would have any human interaction, or any external system interaction.

In some ways, this represents a different way of thinking from a Microsoft data-centric-binding point of view. Their "tools" driven approach has always had a "domain model" alternative, but it's much more prevalent in solutions involving complex domains in Java.

When I say domain model - that is NOT a bunch of data, encapsulated as objects (or "aggregates"), manipulated by some procedural "controller" or "manager", in a (too) complex layered technical solution.

>>> "I decided just design viewmodels that holds data the UI can be bound to. Loading that data was not a problem due I introduced an application controller, which can consume repositories and infrastructure services to load data out of a datastore, which in my case is a relational database, but is encapsulated by the repository pattern."

You have no domain model.

Hopefully, this at least gives some food for thought. Let me know if I can help.

Best regards, Aryeh

[Sebastian Schabbach]

Thanks Aryeh for answering my request in this user group. So let's go though your the points of your post. 

 

First a caveat, I would consider if DDD applies at all to your application. If a problem domain is trivial or non-complex, or if it is in the computer domain, you might be better off writing simple procedural code or another alternative.

 
So, this point is really difficult, but very interesting in the current project. The overall think is that i am currently not able to decide which software is DDD related, and which software is not. On my currently point of view I always have to thing do the DDD approach, if there is a real business in background of my software. In other word there is a domain specifiing they can work with the produced artifacts or not. I mentioned i am wrinting the software for my own, but let's change the perspective a little bit. For a short time, let's say i am not the software architect, I am the domain expert. In fact that szenario is telling the true, as I am self-emplyment in doing some work and the application will help me to document the work that has been delivered. From this perspective I think I am the domain export, but going back to the orginal scenaio, I am devloping the application as well. Some parts of DDD does not match here, there won't be any problems with an ubiquotos language e.g., because the domain expert and the it expert is the same person. It is difficult to handle, but I think (idenpendenly if DDD is the best choice or not) as an example project that wont loose any money, this project is exellant there to start learing some DDD (as well as I know it is constructed).

In some ways, this represents a different way of thinking from a Microsoft data-centric-binding point of view. Their "tools" driven approach has always had a "domain model" alternative, but it's much more prevalent in solutions involving complex domains in Java.

When I say domain model - that is NOT a bunch of data, encapsulated as objects (or "aggregates"), manipulated by some procedural "controller" or "manager", in a (too) complex layered technical solution.

Okay I heard about data-centric applications that will not pass through DDD in a session. But I does not recognise, that this is related to the Microsoft Binding mechanismn. So my question here is: Is there any application that is independend from any UI layer? I think there is no example in the real world. I thought to remember that I wrote my viewmodels are only collecting data for displaying results to the views. This is not related to DDD, but these viewmodels should only contains view "business" logic, e.g. provide a string that is displayed in a textbox. On the other hand the binding mechanism is no magic way. If you are comming from the java community, you can compare it with a swing ui and an observer pattern, which is the idea of the MVC Pattern on the client site (not the Web architecture MVC pattern). So if it is easier we could follow the discussion switching to that point of view.

Here is my questions: Is there any psych. ambivalence between DDD and Data Binding, especially using Patterns like MVVM?

You sayed, I does not have an domain model. So the statement you quoted, belongs to the UI. The UI is decoupled from the domain and you are right, my viewmodel has no domain model. But I have a domain model, at the core of the application. From my point of view now there must be a solution that allows the UI to consume the domain model.

My answer? Represent your element of human interaction (e.g. a window, report) as an object. Have it call a method on an object in your domain model. What, no 10+ tiers, frameworks, patterns and technologies? :)

So you suggest that the viewmodel (equal to view dialog class in java) should hold the model, but is only allowed to call methods on that model instead of setting properies? Sounds interesting, but should be view logic know it's domain model?
The other question, I raised yesterday when thinking about it, how to handle to display changes in the model? Some changes could be ui relevant, that means, if the domain changes it's state, the ui should change too....

I am not sure about that point.....

Sorry for making the discussion that big and raising so many questions....

Regards,
Sebastian.

[Aryeh]

>>> "The overall think is that i am currently not able to decide which software is DDD related, and which software is not."

Domain Driven Design is appropriate if you have determined that an object domain model can best represent the problem under consideration. That architectural choice can depend on many things, but primary is the complexity of the problem domain itself. Other non-functional requirements will influence that choice.

>>> "On my currently point of view I always have to thing do the DDD approach, if there is a real business in background of my software."

I would disagree, depending on the complexity of the domain, non-functional requirements and commercial constraints, I might choose or suggest an alternative.

>>> "For a short time, let's say i am not the software architect, I am the domain expert."

That's great, it makes it easier to have one common model understood by both. That is what ubiquitous language is about. It's not about producing a glossary of terms.

>>> "Some parts of DDD does not match here, ..."

I don't understand this part.

>>> "Okay I heard about data-centric applications that will not pass through DDD in a session"

Also not sure I understand this.

>>> "So my question here is: Is there any application that is independend from any UI layer? I think there is no example in the real world."

Certainly, one can have an application with no UI. It is quite common to have an application with only a programmatic interface. In an age of (micro)services and api based UI's, its quite common?

>>> "Here is my questions: Is there any ambivalence between DDD and Data Binding, especially using Patterns like MVVM?"

I think you probably mean conflict rather than ambivalence? In that case, the answer is no.

... "The goal of domain-driven design is to create better software by focusing on a model of the domain rather than technology.", Eric Evans, Domain Driven Design p148 (emphasis mine)

Best Regards, Aryeh

...

[Greg Young]

>>> "The overall think is that i am currently not able to decide which software is DDD related, and which software is not."


"Domain Driven Design is appropriate if you have determined that an
object domain model can best represent the problem under
consideration. That architectural choice can depend on many things,
but primary is the complexity of the problem domain itself. Other
non-functional requirements will influence that choice."

Could also be functional to be fair

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dddcqrs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[@yreynhout]

It would help if you specify what exactly it is you are building. The typical home for domain invocations is an application service/command handler. I have no insight into whether you're developing C/S or using a multi-tiered approach, which opens up different options of how to go about things with less/more ceremony.