Few relevant postings to read:
A colleague pointed me at a few interesting articles (Replicant) centred around state replication. For a long time I’ve been interested in state replication – I’ve blogged here and there about it over the years. The ability for each replicate to accept change, and propagate change to all replicas ensuring consistency is an interesting problem to solve. Such solutions off interesting scalability options in distributed applications.
Mencius offer more of what I’m interested – single/multi leader
Continuing with Vaughn’s book, page 22 table 1.4 offer a nice view of writing code that models the business – physical and conceptual domains. Page 25 hits the nail on the head with reference to software engineers not being able to pursue technologies and techniques just because they sound cool – well said Mr Vernon!
Page 33 touches on the issues of data-centric models, compared to business domain behaviours. All to often we see in code bases that the data payloads have become some warped domain model within the code base, leaking though every layer possible.
I feel page 37 should have referenced two three letter acronyms, BDD and TDD. However, at least early on in the book reference to test-first development was made :)
Back to page 26, and selling DDD to your boss. If you in software development, and your boss doesn’t know about DDD, then you have bigger problems that just selling DDD.
Page 113, over use of architecture patterns speaks to the ivory tower that one often find with architects. I’ve been in too many banks where the ivory tower enterprise architects perceive they know best, yet have become disconnected from the business, and usage of architecture patterns within real-applications. Further, using architecture to mitigate the risk of failure provides an ROI that offers true value, rather than an anti ROI value based on architecture alone – justification of architecture married to the function requirements! Page 144 harps back to my view of the sweet shop – using architectural styles and patterns because they are cool tools :(
Layer’d architecture (page 119) reminds me of how often I worryingly see applications where basic architecture has been forgotten, leading to leakage throughout the application. This in itself leads to tighter coupling, which will inevitable cause problems in the future.
Event sourcing, page 160, is an appropriate read, aggregate state snapshots :)
Type of tests – page 239. Unit tests and behavioural tests both have their place. Embrace change.
“Design you data model for the sake of your domain model, not your domain model for the sake of the data model” – page 250
Modelling events (page 288) and publishing events (page 296) offers an appropriate read, coupled with one of my favourite diagrams for modelling interactions – the sequence diagram (page 299). Think distributed systems. Be thoughtful of timestamps on events – clock slippage.
“Problems always arise with integration when developers who are unfamiliar with the principles of distributed system gloss over its inherent complexity” – classic statement (page 451). Reminds me of all the software engineers who have told me they can write thread safe code, and yet fail to understand the complexity of cores, latency and more
Appendix A offer a good read on event sourcing, with an appropriate :) selection on testing and specification – Given-When-Expect
InfoQ offers an interesting read on agile planning and estimation. Here are a few key quotes :)
All numbers are based on assumptions. Your figures are only as good as your estimates and guesses – and there may be serious flaws in your assumptions.
If we approve a project based on a year’s worth of work, and we estimate it and we think it is all good, there is a lot of risk inherent in there. But also, and this is worse, we might ditch doing something really, really valuable for the company because we have clumped together all this value into a year-long project and we are making a really big decision – to go or no go – based only on that clump.
Big, up-front project thinking is essentially a lot of assumptions. According to the traditional assumption life cycle, we have business requirements, functional requirements, and they turn into development and then delivery. Actually, these business requirements that we come up with are all assumptions. We do not actually know these things are valid at all. We say, “Well, these are our business requirements. Let’s decide how we will deliver those and get some functional requirements around those”. These are just hypotheses
“Behind the Curtain of the HealthCare.gov Rollout” offer a few excellent quotes. I particularly like the quote around the number of concurrent users:
After the launch, HHS officials sharply criticized CMS’s management leading up to the launch of Healthcare.gov. Referencing an email in which a CMS official admits the system could not handle more than 500 concurrent users, Mr. Baitman wrote “Frankly, it’s worse than I imagined!” and Mr. Sivak replied, “Anyone who has any software experience at all would read that and immediately ask what the fuck you were thinking by launching.”
“These bugs were functions of volume…. Take away the volume and it works.”
Clearly from the above some basic principles around project management, software engineering and requirements were “forgotten”
Oracle GoldenGate and HotCache offer an interesting (but expensive) solution to solving certain classes of problem. Assuming an application stack that is Java, leveraging Oracle Coherence, backed by an Oracles database, where the application stack is installed in two locations, with the requirements for bi-directional replication of data, so each application sees the others data, and can perform actions on the data. GoldenGate leveraging HotCache provides a mechanism to achieve replication, with the added benefit that not only does the data get replicated between databases (GoldenGate), but that Coherence state is updated as well (HotCache).