Automapper? Model and Domain layer in api

I’m new to F# but would like to start building an API with it.

I have previously built c# API’s. In those we layer the architecture between models (being in the controllers), the domain DTO’s in the services and finally in the data layer if there needs to be any persistence.

Between these layers we use Automapper to map the types up and down the layers keeping a clean separation, for example none of our domain objects can have anything null in them (we use a maybe/option) and cater for this in our mappings between the objects.

I have seen examples of building API’s with F# but no good examples on architecture. I have also see Automapper used on a stack overflow with F# but it seems hacky to me.

I’m just wondering what people do. Do you use something like Automapper in F#, do you keep a separation between your models and domain DTO’s? do you care?

Any help would be appreciated. Thanks

I have never used AutoMapper myself, but I suggest you try the approach posted at

This is just over a year old, so it should be using most of the current features of F#.

I know the OP and the reviewer are both very knowledgeable.

Regarding domain modeling, you should read this book by Scott Wlaschin (also the author of

You should also be able to find some great videos by Scott on this topic, probably on youtube.

This question was reposted from

Would you say that AutoMapper is the correct thing to use to map DTO objects between the model layer and domain layer.

Is that something you would do in keeping a clean separation of concerns?

Yeah I thought it was worth asking there too.

It’s not a question that seems to get asked a lot. A great many blogs using Giraffe or a video on youtube on “getting started with core” etc but what I’m looking for guidance on is Enterprise best practice. I want to start using F# right and making these architecture decisions and getting them right is critical especially if there are those around you who are critical to begin with.

Mostly reposted from SO. I’m not sure which thread you prefer to maintain. Which is the original and which is the repost? Then we can mark one as a duplicate.

DTOs are intermediate serialization-friendly objects. It’s a lot of code to create these, and then you have to create hints about the maps if mapping automatically, and you have introduced reliance on reflection (slow), introduced a type-unsafe automation system in your code, and end up with inefficient serialization.
Just as much work as writing the serialization directly.

Would you expose a database DTO from the data layer of your application to the top level, say as an object that gets serialized to JSON and exposed through a controller?

To quote the AutoMapper website AutoMapper is a simple little library built to solve a deceptively complex problem - getting rid of code that mapped one object to another. So essentially in C# when using in our API we have similar DTO objects at different levels of our application. AutoMapper helps (and can sometimes map automatically) one model DTO to a domain DTO , this keeps a separation of concerns between the layers, and allows us to map classes that may contain null in the model layer to values in domain layer to have an Option which we can add in a custom mapping.

Really what I’m asking is, do you as an F# developer worry about a separation of concerns between different layers of your application? Do you have Model, Domain, Data layers in your application? Do you follow anything like onion architecture?

I started this thread first and wrote the SO one second.

Thanks for the response

Why do you need a library (AutoMapper) to construct an object from another? The constructor will work just as good and won’t hide logic from you while reading the code. Let go of AutoMapper and just use what is already there in the language. The constructor of a class is the most important method (IMO).

1 Like

Yes. The Onion (aka Ports & Adaptors) style architecture is preferred. There are numerous blog posts about Domain-driven Design in F#, particularly on and

I personally do not use AutoMapper as a matter of principle. I prefer explicit mapping between Domain Types and Web/persistence DTOs, although I can appreciate that some people may prefer a “semi-auto” solution like AutoMapper. My reasoning is that the shape of DTOs will usually be determined by the type of web framework (json serialization method for example) or the persistence mechanism (eg. Dapper). IMO, doing the mapping explicitly is less likely to allow peculiarities of the web/persistence frameworks leak into the domain code.

Domain types, on the other hand, are designed to describe the domain as precisely as possible. Domain models in F# typically make heavy use of discriminated union types, which don’t translate well to Json or SQL dtos.

The way I typically design applications is by starting with the Domain types and the business logic. Once I’m certain all this works (via unit tests for example), then i work my way outward to the boundaries of the application, which usually includes a web interface and persistence interface. I write “adapters” that do the translation between the domain types and the adapter-specific implementations that use their respective libraries/frameworks for web and persistence.

I can’t speak for everyone, I’d say this is considered best practice in the F# community. Would definitely check out this series: and this post:

1 Like

Thanks for the responses, yes I have seen that there is another way. I have picked up Domain Modelling Made Functional by Scott Wlaschin