CODEWITHSUNDEEP
c#wpfmvvmarchitecturedomain-driven-design
Marshal
Marshal

Reputation: 6671

Converting WPF application to follow DDD

I am trying my hands at DDD for the first time, and got stuck in the middle.

Current Design: Our current design, not elegant but simple and works. Views bind to ViewModels, and ViewModels have reference to the ServiceClients. When user requests something on the View, it changes the state of ViewModels, and ViewModels in-turn requests ServiceClients. ServiceClients can respond to the requests either synchronously, or asynchronously.

Pros: Very simple design, and works.

Cons:

  1. Tightly coupled to everything, everyone needs reference to everything to get things done.
  2. Violating SOLID largely.
  3. God objects every-where
  4. Not testable at all!

DDD: I decided to take refuge in DDD, to get rid of all the cons mentioned above. The idea was to carve-out Models from ViewModels, and break dependency between ViewModels and ServiceClients. So far so good.

The major issue I am facing here is the project is becoming highly event driven now. I have to fire a lot of events to get a simple operation executed.

For instance: If ViewModel has a request for ServiceClients

  • ViewModel will invoke an operation on the Model object,
  • Model fires an event, which ServiceClients handle.
  • ServiceClients will invoke an operation on Model to send response
  • Model will fire an event, which is handled by ViewModel to receive the response

The question is: 1. Is the architecture laid out correctly? 2. Is eventing necessary to get simple things done?

Thank you for your time.

Upvotes: 0

Views: 701

Answers (1)

Subhash
Subhash

Reputation: 3270

Without knowing sufficient details about the actual use-case, I would venture and say you are facing this problem because you are only applying the tactical patterns of DDD without spending enough time on the strategic side.

Let me explain.

Even when there is an existing codebase like you do, you want to start thinking about high-level boundaries in the system, key actors, their behavior, and interactions between key actors. You should identify the different bounded contexts in your domain and the connections between them.

More importantly, you should try to capture the domain functionality as-it-is in the codebase. By that, I mean representing concepts in the application to mirror what a domain expert would say.

If you take your existing codebase and directly try to apply the domain modeling concepts of Aggregates/Value Objects/Domain Events etc., what often results is spaghetti code where everybody references everybody else, and dependencies are left unchecked. This interdependency leads to a situation where an update in one part of the system triggers an application-wide change and needs the extensive use of Domain Events.

Further reading:

Upvotes: 1

Related Questions