-
Notifications
You must be signed in to change notification settings - Fork 0
Log
Latest activity/paragraph @ top.
Not sure how to manage now this Log, as I sliced this project into several repositories. Probably i will leave this repository just to capture some of my progress, interesting resources or... whatever. Basically today mostly working to structure protobuf API repository. Reading on Uber and Google style-guides.
After some talk in Slack, it seems that monorepo will not be the best choice. Started to see, how i can set up multiple repositories. Not sure, should i use single repository per sub-domain and include all services (gateway, command, event-handler, denormalizer, query, etc) int that single repository OR i should create separate repository for every single service.
In order to understand project architecture today spending time on learning about Go interfaces and composition.
Last days spending time on reading The Programming Language and watching Ultimate Go Programming No coding
Yesterday and today pretty much did nothing. Feeling frustrated that every sample repository i find in GitHub are pretty much a garbage from perspective of project management and ability to scale it. Every of them shows only one aspect and lacks many other important aspects of idiomatic Clean/Hex arch. Collected bunch of Chrome tabs and trying to combine everything. Nothing to commit. :(
Yesterday and today still spending time on browsing Google and reading about Clean, Hex, Onion, Port & Adapters architectures. Definitely feel that this is direction i want to move on as none of my earlier attempts to bring in at least some structure into project was totally failing. None of them felt right. Hardest part is to find practical examples in Go. There are some, but they all incorporate some level of modification on each. Naming. Folder structure. None of them feels right.
By reading all this... it kinda makes sense to me, but it's hard to build mental map expressed in Go code and Git repository structure.
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
Today spending time on reading about Haxagonal architecture.
Moved /build directory out of service to root level. Modified Docker. :) It think, I like the shape of project it start to take.
Moved proto stuff at top level /api directory. Feels right.
Merged Develop to Master and recreated develop from master. Found nice Docker container to spin up Kafka suite for development landoop/fast-data-dev.
Can't figure out how to deal with *.proto and vendors. I think, vendoring, if used, should be located at root of the project, but this means that all protoc shell scripts at any directory level should point to root vendor, which will lead to --proto_path=../../../../../../../../../../vendor kinda thing and i don't like that.
General thought is to have all IDLs and Protobufs at some constant location so all sub-domains could use it. Currently Proto-stuff are hidden inside of application/service directory, which i feel is not right.
Made some small project reorganization and moved code from /domain to /internal. Introduced high level domains
like /core, /shipping, /web.
Somehow it feels right direction.
Spending a lot of time to learning about high level Git workflows. Experimenting. Probably f***d up this repository history. But at least it still works. :D
Currently managed to Dockerize ./domains/public/ (UPD: Renamed to /internal/web/public) (multi-stage scratch build) which is public frontend.
I think i will split front-end in two parts.
- For public guest users and
- For authenticated users.
I am thinking on splitting front-end in self-contined components (Composite UI?) where each component could be deployed independently by its team, but ... it leads to some questions i should research. Like, how to manage composition of those components. How to handle Redux part in such case because every component would have its own independent redux store, but if every action exchange would happend via HTTP/2 / WebSockets and supporting backend services, this would lead to somehow slow UI. A lot to think/learn of.
As well today i made Storybook implementation. It seems to work. Next steps would be to split that into separate Go webserver.
Some of next tasks/milestones would be to implement User domain services to Sign Up, Sign In, Restore Password.