Unblocking my blogging - recent progress at Arkency Ecommerce project

#blogging #rails #opensource #ddd

Recently I've been struggling with a blockade in writing posts. It's not the first time nor the last one, so I learnt to accept it.

In the past what helped me is just documenting what I'm doing as blogposts. When you document you focus on what you did. It's almost like a written/async standup. When I try to teach or express opinions as a blogpost things are more difficult for me.

I'm lucky to be able to work on an open source project. Which means I work in public. It also means I can freely share the progress.

I will probably write some posts here, then move to the Arkency blog.

So as an attempt to unblock myself, over the next days I'll share a few small things I did recently on the Arkency Ecommerce project.

The project is an attempt to implement an ecommerce/order-management-system in Rails but fully using Domain Driven Design, Event Sourcing and Command Query Responsibility Segregation. If you don't know those buzzwords, don't worry. It's just difficult names, for simple things. Feel free to ask if something is not clear.

One recent small issue was open source related.

Someone asked "what is the license for this project". The problem was that in the past, this repo was just a typical Rails app with its typical structure. The LICENSE file resides in the main directory.

However, once we went further with the idea of separating the domain code from the Rails app, we changed the directory structure.

We created rails_application subdirectory and moved the rails app over there. Then in the main directory we created ecommerce directory which contains the business modules (aka bounded contexts).

The LICENSE file was moved together with the Rails app. This means that it was no longer following the convention of keeping the LICENSE file in the main directory.

✗ tree -L 1     
.
├── Makefile
├── README.md
├── ecommerce
├── hanami_application
├── infra
├── math
└── rails_application

BTW, we deliberately have the MIT license, so that people can do what they want with this codebase. This project has many educational goals. It's a bit of a challenge too, because of this. When we experiment with new ideas, some people may feel like this is what is now "recommended" and copy the experiments too. I guess that's the risk of doing things in public.

As a fix for the problem, I moved the LICENSE back to the main directory.

I was seriously considering writing a test for that. This is an important convention to keep the license in the main directory. We're usually very brave with refactorings here. This means we're at risk of regressions of such trivial things too.

What do you think?

OK, I think that's enough for an "unblocking" blogpost. I know it was a trivial example. Hopefully this unblocks me and more interesting posts are comming soon 😎

Top comments (5)

Paweł Świątkowski • Aug 4 '22

I would call it "CI check" not a test - as tests should IMO be related to the application logic only, not all the supporting infrastructure. But the idea is not bad at all.

Makes me think about more checks like that. For example, if you keep docs in separate files than the code, you can check if when the files are updated with a lot of added code recently, did the doc files changes as well.

Andrzej Krzywda • Aug 4 '22

An interesting perspective with the CI check.

I agree, that this test/check is a bit different. However, technically, where would that check be "implemented"? Still in the same repo? Would it run also locally on dev machines?

I'd opt for the same repo and run on dev machines.

Paweł Świątkowski • Aug 4 '22

Good question. I'm used to keep these kind of checks in the repo, but separated from the app (for example in a .ci directory in repo root). I rather don't expect them to be regularily run on dev machines, unless someone needs to debug why the check is not working as expected. This is probably why it's easy for me to draw the line between "tests" and "checks".