|
I've been using a very similar architecture on an application for about 2 years now, and it's been incredibly smooth to work with, especially in Go (passively satisfied interfaces and enfirced lack of inheritance), though I do feel like the article overcomplicates the design (also recommend looking up onion architecture). Basically, for me, it boils down to the following: 1. Create domain package(s) with the basic business entities (users, vendors, products, etc) - can't import anything.
2. Create usecases package(s) that acts on these objects and can import anything in the domain package, but nothing else (though can accept repository store interfaces).
3. Create infrastructure packages for taking to databases, caches, etc - can't import from rest of application.
4. Build repository stores to translate between repositories and domain objects (can import domain and usecases, and accepts interfaces for infrastructure).
5. Add controllers/main packages that build repository dependencies with infrastructure config, and pass those interfaces into usecases that do the necessary work and spot back results (imports everything). The end result is a bit topsy turvy to get used to at first, but then it's a dream. Extremely easy to test (very little dependency coupling in each package), and the most complex parts of the application logic are totally isolated from the complex parts of the infrastructure, so you end up with less cognitive load when dealing with either. After my experiences so far, I can't see ever switching back to "top down" architecture instead of "inner out" when given a choice. |