Fork me on GitHub

Not a big fan of self-promotion but some of you might find this report (released in August last year) about my relocation from the city to my hereditary home up in the highlands of Georgia interesting, although it's in Georgian - A video -


How does everyone go about splitting dependencies up into separate libraries for business applications? I realised today I only know what I've "learned on the job", so to speak. It came up when someone wanted to merge all our business logic, entities, data-access etc. (everything except web APIs) into one huge project.


Despite the fear of being condescending: Most likely, your customers don’t care how you organize your codebase. So you’re doing this for some other reasons. Enumerate these reasons. By asking why you will most likely end up with the root problem that you’re trying to solve. Off the top of my head, I can think of some problems to which splitting up a monolith into several libraries would be a solution, one being that you can have different teams move at different speeds without much coordination. This I believe is part of the sales pitch for microservices. Microservices also come at a cost. Note that I’m not suggesting that you should/should not go for microservices, I’m suggesting that you understand the tradeoffs of your potential solutions: Every solution comes with trade offs. Enumerate those. Don’t forget to enumerate the trade offs of doing nothing. Doing nothing, or kicking the can down the road, is often a really nice solution to a problem. It let’s you spend time on more interesting problems, and it also lets you gather more information, which in turn might lead you to other and better solutions to your problem. Rich Hickey has an excellent talk on this, Hammock Driven Development,


You're right, it seems there's nowhere near a universally applicable method for this. To the hammock I go!


@michael.e.loughlin Not sure what you're asking... You have one big project and you want to make parts of it into reusable libraries?


The proposal is to merge 5+ different products into a monolithic megalib. They're developed by different teams, but occasionally someone will need to do work cuts across the teams. My initial reaction was to disagree with the proposal, but I have no real references.


So I thought I'd re-evaluate my point of view.


Ah, so it's really the opposite? Taking multiple, currently-separate products (in different repos?), and merging them into one code base (in a monorepo?)... If it's any help/consolation, we have a monorepo at work with 94K lines of Clojure and about thirty subprojects within that, from which we build about a dozen separate apps. We find it a very convenient way to work -- but we're a very small team so we don't step on each others' toes much.


Yeah, basically the opposite. I don't oppose a mono-repo as we're also a small team and have a few pointless git submodules that could happily disappear. What sent my intuition hay-wire was this "do everything" library - all applications have knowledge about all others, whereas previously they would only have access to the specific internals. On reflection, it's not really a huge deal either way & until it starts to impact some measurable metric I'm not going to worry about it!