I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:
In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):
- Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
- Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
- Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
- Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
- Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
- Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht
git branch -m old_branch new_branch # Rename branch locally | |
git push origin :old_branch # Delete the old branch | |
git push --set-upstream origin new_branch # Push the new branch, set local branch to track the new remote |
- Broadway - Infrastructure and testing helpers for creating CQRS and event sourced applications
- EventCentric.Core - Event Sourcing and CQRS in PHP
- LiteCQRS - Small convention based CQRS library for PHP
- predaddy - Common DDD classes including an annotation driven message bus and tools for CQRS and Event Sourcing
- ProophEventSourcing - Provides basic functionality for event-sourced aggregates
- ProophEventStore - PHP 5.4+ EventStore Implementation
- ProophServiceBus - PHP Enterprise Service Bus Implementation supporting CQRS and DDD
The always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the
The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.
- Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
- Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
- Once documentation has been written, development should commence, and test-driven development is preferred.
- Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
- When a feature is being modified, it should be modified documentation-first.
- When documentation is modified, so should be the tests.
curl -s https://api.github.com/orgs/twitter/repos?per_page=200 | ruby -rubygems -e 'require "json"; JSON.load(STDIN.read).each { |repo| %x[git clone #{repo["ssh_url"]} ]}' |