atsapura/cardmanagement

Card Management

Why?

This is a "real world" example application, written entirely in F#. The goal is to create a best practice for building applications or at least give a reasonable manual to design one.

Summary

It's a very simple bank application.

Here you can

• Create/Read users
• Create/Read cards for those users
• Set daily limits for cards
• Top up balance
• Process payments (according to your current balance, daily limit and today's spendings)

Tech

To run this thing you'll need:

• .NET Core 2.2+
• Docker
• Visual Studio 2017+ or VS Code with Ionide plugin or Rider with F# plugin

Database here is MongoDb, hosted in docker container. So you just have to navigate to docker folder and run docker-compose up. That's it.

For web api Giraffe framework is used. You can also play with it using CardManagement.Console project.

Project overview

There are several projects in this solution, in order of referencing:

• CardManagement.Common. Self explanatory, I guess.
• CardManagement. This is a business logic project, a core of this application. Domain types, actions and composition root for this layer
• CardManagement.Data. Data access layer. Contains entities, db interaction functions and composition root for this layer.
• CardManagement.Infrastructure. In here you'll find a global composition root, logging, app configuration functions.
• CardManagement.Console/CardManagement.Api. Entry point for using global composition root from infrastructure.

Detailed description

Here's long and boring explanation of why anyone would even bother to use F# for web api and tips on how to do it in such a way so you don't blow your head off.

cardmanagement's Issues

Question about where contract mapping code lives

Not really an issue, but there wasn't a discussion forum or I'd have put it there.

I've been reading through your (fantastic) article, I think you bring up a lot of really great ideas.

Curious if you'd be willing to expand on your opinion where the contract mapping code lives in the Domain project.

Normally I've been keeping the contract code purely to the boundaries of the application. My thoughts are that it is the concern of the WebAPI layer to define/maintain the definitions of how the domain aggregates are represented to other systems. Similar to how you've done it in the Data layer. The Data layer is concerned with the representation/mapping of the domain to however it looks when persisted to the database.

Would you argue that the definition of the exposed contract is the concern of the domain? I'm not trying to push one way or the other, just interested in hearing you expand on your thoughts..

Propagate article name change to Readme.md

Link is broken at the moment