Is DDD necessary in my WPF+WCF scenario?

Question

I am developing a WPF application, that connects to several WCF services (that work with LINQ-TO-EF).

The WPF is designed in MVVM fashion.

For each WCF Service I have the following:

• Service Layer DLL - this includes the service interface, service implementation. the service implementation just creates BL objects and calls methods on them
• Service BL Layer DLL - this includes a manager factory (factory creates UserManager, TaskManager etc). Each manager has an interface + implementation (for unit-testing purposes and DI). For example - TaskManager has 'GetTasks', 'CheckTaskIsValid' etc. In addition, the BL Layer has a 'Trasnlator' class to translate from Data-Entity to DTO. The BL manager methods return DTOs to the service layer.

In addition to the above, all the service BLs reference the Data Access Layer DLL that includes:

• EDMX file with tables from MS SQL Server
• Auto-Generated DbContext + POCO entities
• Query providers (used by BL manager classes). Each query provider has an interface+implementation for unit-testing and DI purposes.
• DbContext factory - interface+implementation, for unit-testing and DI purposes.

The services are in CQS design (Command-Query-Seperation, not to mix with CQRS), meaning that there is one service responsible for querying only and one service responsible for sending commands.

I am using DI (using AutoFac) through my WCF Host Project that hosts all the services (I implemented IInstanceProvider, so that I can inject dependencies to the services).

I did not implement my own repositories or unit-of-work, because DbContext already is UoW and Repositories.

Is this design flawed ?

I have read a lot of posts about DDD, and I know that my design is not DDD.

My question is - is my design good enough ? Do I need to refactor all my code towards DDD ? (using aggregates and root aggregates etc).

I have tried to provide as much detail as possible about the design, so I hope I don't get answers like 'Your question is too general' or 'Need some examples'... Any helpful information would be very much appreciated !

Answer 1

Yes, you have not DDD design, but not-DDD doesn't means bad design. I think when your system is testable and flexible for further development, scales good for your needs - than you have good system design for your needs.

All other sounds good except:

I did not implement my own repositories or unit-of-work, because DbContext already is UoW and Repositories.

Not implementing your UoW and Repositories means you are tightly coupled to Entity Framework and it could be problems with testability. But you can cover it with integration test again test database. Unit tests for database logic sometimes tests itself.

Do you need DDD? Maybe when system will be more complex than evolutional you will come to DDD and to CQRS. But when it's enough for you, easy to maintain and for further development, testable, scaling, when system is not fragile, than I think, it's better to focus on business needs