0

I followed a few courses on Pluralsight about Clean Architecture and Domain Driven Design. While I'm waiting for Eric Evan's book about DDD to arrive, I got the following situation and question:

I'm setting up a new project. I've added the following projects:

  • MyProject.Application
  • MyProject.Common
  • MyProject.Domain
  • MyProject.Infrastructure
  • MyProject.Persistance
  • MyProject.WebApi

A business requirement is to let the WebApi return a model with some properties that:

  • Don't match my naming convention;
  • are ugly.

This model lives inside the MyProject.Application project. For example:

namespace MyProject.Application
{
    public class MyModel
    {
        public string _communityname { set; get; }
        public List<string> photolist { set; get; }
        public string postedby { set; get; }
    }
}

Usually I would apply the JsonPropery attibute on these kind of models to keep it nice:

namespace MyProject.Application
{
    public class MyModel
    {
        [JsonProperty("_communityname")]
        public string CommunityName { set; get; }

        [JsonProperty("photolist")]
        public List<string> PhotoUrls { set; get; }

        [JsonProperty("postedby")]
        public string PostedBy { set; get; }
    }
}

But, then I think about it... and say to myself: the application layer should not concern about how 'things' are presented. This is a task for the presentation layer, in this case WebApi.

Is this correct? Should the Application layer return a normal model and let the WebApi cast/convert this to any (ugly) form of presentation, required by the business.

Many thanks in advance.

JonHendrix
  • 933
  • 15
  • 28
  • 1
    I can't say with any certainty this is the proper way, however, I would probably have a one-off model for WebApi that I'd map to and that way I can cover it with any attributes I want and it won't affect my Application's Model. – TyCobb Jan 20 '17 at 15:26
  • Yes. I'm also considering this option. It's just one, perhaps two end points that need this 'adjustment'. I'm looking at Fran's anwer and wil come up with a plan – JonHendrix Jan 20 '17 at 15:39
  • 1
    @Tweek I always use separate view models in my WebApi/MVC projects because it decouples my internal domain logic from that of the UI/REST. I think it's a cleaner. See http://stackoverflow.com/questions/4878937/why-should-i-use-view-models – Fran Jan 20 '17 at 15:45
  • I agree. Decoupling this makes it more cleaner. The Query (CQRS) will return a list of models, designed en implemented conform the use case. The WebApi project will fit the results into the shape it's required. When the EndPoint requires another contract, I've only to change the API, not the Use Case in the application layer. – JonHendrix Jan 20 '17 at 19:43
  • > Should the Application layer return a normal model and let the WebApi cast/convert this to any (ugly) form of presentation, required by the business - Yes. This is the right thing to do. – Alexey Zimarev Jan 22 '17 at 15:45
  • Today, I wouldn't suggest getting into DDD by reading the blue book. Get "Implementing Domain-Driven Design" or "Patterns, Principles, and Practices of Domain-Driven Design" instead, and read the blue one only afterwards. – Vladik Jan 30 '17 at 21:06

2 Answers2

0

I'm not sure what MyProject.Application actually does? But I'm going to guess that it's not your REST endpoint since you've got MyProject.WebApi.

I'd move it to the WebApi project because it is only involved with showing a specific data format to your users. I'd add a Models or ViewModels folder to the WebApi project and keep any objects you are exposing through the REST endpoint. And do the tranformation from domain model to "view model" either in the controller action or a service in the WebApi project. One of the keys is not exposing you domain model to the outside world.

Also check out this video from Eric Evans about what he's learned since his original DDD book was published. https://www.infoq.com/presentations/ddd-eric-evans

This question is probably better suited for https://softwareengineering.stackexchange.com/ than StackOverflow.

Community
  • 1
  • 1
Fran
  • 6,440
  • 1
  • 23
  • 35
  • Thanks for the swift response and pointing me to softwareengineering.stackexchange.com. I'm certainly going to view Evan's video. – JonHendrix Jan 20 '17 at 15:41
  • I'm coming from many years of classic 3 layer (database driven) application design. I'm forcing myself to this DDD/clean design. From what I've got so far, the application layer will be the layer to implement the use cases as executable code. It will be structured as high-level application logic. It knows about the domain layer (dependancy) but it does not know about the presentation, persistance or infrastructure layers. This is taken from a course by Matthew Renze. – JonHendrix Jan 20 '17 at 15:47
0

If your web api is the only entry point of your application, then I don't think it would hurt to have your DTOs in that project. Usually when you create "application services" these are not necessarily consumed only by the api, which in that case makes you rethink the whole thing.

At the end of the day, your READ MODEL (DTOs) is nothing but a projection of data that you want to return from your 'application services'. The client can be a web api, or any other process that needs to use that service.

Does it make sense?

Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47
  • Thank you for your feedback. I'm just starting this new project. And indeed, for now, the API is the only 'entry point' or 'front end' that presents the data. But I'm not sure if there will be more options in the future. And if so, will it fit in this particular bounded context or does it require it's own bounded context. – JonHendrix Jan 20 '17 at 19:50
  • Remember, your DTOs (or Projected POCOs) are not part of your domain. They actually are completely detached from Domain operations since all they do is to offer data in a way that is appealing to the client/consumer. Usually I have a separate project with a very light weight "data reader" (you can actually use ADO.NET) just to read directly from the Database and project this to my client/consumer. In SQL, you can actually create Views and pull those directly or SPROCs. Up to you. If client needs data in one DTO from 4 different ARs, you just project it in a view and ship it to client. – Pepito Fernandez Jan 22 '17 at 00:35