3

I have inherited some code which is still a work in progress. I think it has a glaring architecture problem:

It has a project that contains all the domain entities (domain layer) and a project that contains all the application services (application layer). The application layer has a dependency on the domain layer. So far so good. Then there is a 3rd project which contains all the view models for the application layer. I'll call this the view model layer. Fine.

Problem is, I've realised that the domain layer has an active dependency on the view model layer. What it is, is they've put a bunch of meta data for every entity in here, mostly the max length of various string fields, and both the domain entities and the view models are referencing these constant values.

I'm pretty sure it's very bad to have your domain models dependant on view models in this way. I discovered this because I wanted to use the domain model for something in a view model and discovered that I couldn't because of the circular reference it would cause.

So my question is this: how bad is this architecture? Or am I actually wrong and it's not a problem at all. I actually can't find an answer to this, possibly because it's considered so obvious. Also, what do people normally do for field meta-data (like max length) which is common to both the domain entities and the view models? Seems a waste to write it out in more than one place.

I'm using c# MVC with angular client for what it's worth.

Thanks in advance.

Dean
  • 85
  • 8

1 Answers1

4

Clean Architecture push us to separate stable business rules (higher-level abstractions) from volatile technical details (lower-level details), defining clear boundaries. The main building block is the Dependency Rule: source code dependencies must point only inward, toward higher-level modules. Higher level modules shouldn't depend on the lower level modules.

Your Domain Models shouldn't depend on View Models. It's breaking the most important rule of Clean Architecture by Robert C. Martin.

how bad is this architecture?

It's as bad as problems it generates. The first one you've already pointed out - you can not reference Domain Models module in View Models module. Domain model is complicated enough because of domain problem it solves. You should not add additional complexity by referencing details (like View Models). Another problem I can think of, the more dependencies you have, the harder it is to test your domain model.

Also, what do people normally do for field meta-data (like max length) which is common to both the domain entities and the view models? Seems a waste to write it out in more than one place.

Validation rules can have different sources, eg.:

  • Technical database limitations
  • Business rules
  • GUI friendliness
  • other?

You should think about each validation rule you have, and decide where it comes from. If validation rule makes sens in term of business rules, I would put it in a Domain Model. Maybe there are some validation rules that should not be in your Domain Model? Hope it helps you a little :).

Take a look also at this article: Data validation

Jonatan Dragon
  • 4,675
  • 3
  • 30
  • 38
  • I strongly second this answer and the implicit recommendation to read "Clean Architecture." – Chris McKenzie Sep 04 '19 at 19:46
  • Thanks for the answer. Naturally, I'm trying to work out if it's worth the time for me to change it or not, which I know is a hard question to answer as you can only really know if it's worth it in hindsight. Most the field meta data is just arbitrary length restrictions. So I'm not sure where that "comes from". Are they there to limit storage space used? Hence they come form the database. Or are they there to encourage uses to input more succinct descriptions, in which case they are business logic. Either way, I don't think the View Models is the correct place for such things. – Dean Sep 05 '19 at 10:48