Just found @anders answer:

but I still can’t get used with this Blog example. For me it looks like some re-usable code (maybe umbrella later) and not real Bounded Context in terms of DDD

I know this might not help you much, but just try to work on your app instead of trying to hard to fit your context structure in some kind of predefined schema. In the end it’s your app; you decide what’s worth splitting up and what’s not. Also elixir makes it quite easy to move things around even at a later time.

For example in one application it might be best to leave those 2-3 functions related to registaration with the other user handling (auth, …), while in another one registering might be a quite complex task with multiple steps involved. In that case the registration is probably better moved in a own context separate from other user related tasks. When exactly it’s time to move things in different context is a decision you’ve to make on your own and as stated is mostly dependent on the very app you’re working on.

Sincerely, since bounded context was introduced in version 1.3, it has been very difficult working on something. It has however exposed me to a new way of thinking. It will be better if @chrismccord and his team furnishes us with samples like they do in aspnet core. This will help us to have good understanding of this approach. I love phoenix but I couldn’t use the version 1.3 on a new project that I am working on because I was confused. I went for dotnet core even though my heart is in love with phoenix.

One important thing - this is not bounded context. The primary aim is to encourage building modular code. If you use DDD and bounded contexts for this - it’s your choice. But it’s just modules & functions until you yourself decide it’s something more in your application.

@michalmuskala This is quite interesting. I voted for no context as proposed by Jose. However as a work around, I am thinking of using the project name as my default context as we would do in entity framework, eg LibrilleDbContext. This will hold all the tables that will be created. If need be for new context, I could then restructure it. However, this does not eliminate the need for samples. This will help ELIXIR and PHOENIX adoption.

I wish I am really good like you in Elixir. You are always there to talk to me whether at slack or here. Thanks

It’s the same with me. It feels more difficult working with Phx 1.3 compared to 1.2. However, I believe that’s because I’m too used to the Rails way…

It’s really interesting how different experiences can be. I’m not coming from rails, but the php world and I’ve had the best time rewriting a website in phoenix 1.3. First I played a bit with the context generators, but I found them to generate to much stuff (whole crud for each struct/schema), so I moved to creating my own contexts. It’s now super obvious where stuff is done as each context handles a single concern of the website. The whole web layer is only there to trigger stuff deeper in the application and to translate the returned values into markup / flash messages / …. I can use the whole app via iex without ever touching a single conn struct, nor any Repo.something() calls. Sure there was some time needed to get worm with that new approach, but I didn’t find that more difficult than trying to use phoenix 1.2 for the first time.

@LostKobrakai it’s good to know you find it very intuitive to work with. If you mind, can you share what you have? Perhaps the github repository if it is not private.

I can’t share the code, but it’s a website where people can register for a local event and I used the following contexts: auth, email, faq, newsletter, pdf, registration, ticketing and support. These where simply the things needed for the website and which felt to be distinct enough pieces of the whole. That’s why I think nobody can really tell anyone else what contexts they should use.

Thank you, thats what confused me. So contexts in terms of Phoenix means just module scoping and not real DDD? Just for @chrismccord answer at forums it looks like real DDD bounded contexts:

And when examples for different usages (module organization, DDD contexts to scope UL) appears here - I get confused