Rinat Abdullin on Efficient Software Development

[...] About Event Store As you probably already know, Greg Young built a file-based Event Store with a team in Ukraine. The product was publicly announced last September and now they are [...]

[...] In reply to the question from Stacy: Does your event store only serve one node type? Or does your event store serve any and all nodes? I did it in various [...]

[...] . Administration Here are a few considerations and assumptions that affect our requirements for Event Store server setup: Uptime with many nines is not critical for at the moment. Built-in Azure [...]

[...] . Currently I'm working on gradual migration of our systems towards centralised EventStore on Windows Azure. Some community members expressed an interest in the process, so I'm sharing my current [...]

[...] I’m working on gradual migration of our systems towards centralised EventStore on Windows Azure. Some community members expressed an interest in the process, so I’m sharing my current [...]

[...] , where almost all changes are tested as they go through the scheduled regular releases to Windows Azure. Development teams have multiple developers (even though they can be moving between projects [...]

[...] ); Worker - console to run app server locally, it also acts as a worker role that can run on Windows Azure cloud. That's it. This is the only project-specific code of the application server that runs [...]

[...] 's my interpretation, which tries to stay as close to the origins as possible. We apply Domain-Driven Design to help solving problems in some vast and complicated problem space. This problem space is [...]

[...] . by applying basic techniques from object-oriented software programming, messaging and domain-driven design, one can build rather decoupled software that is relatively simple to reason about. Low [...]

[...] of the mess in my examples). So let's have one more try in getting things right. So in Domain-Driven Design, domain is a part of business reality that is so important for us, that we want to capture [...]

[...] Domain-Driven Design can often lend a helping hand in diffusing a tight political situation in a conservative [...]

[...] once said "Writing is a thought that you can analyze". In the world of software design we can push it even further and say that "Code is a representation of the problem [...]

[...] podcast and is covered there. We are writing this task manager as an exercise in software design and a few specific design patterns and approaches: event sourcing; command-query [...]

[...] (e.g. put the ones that are used most frequently - upfront). Same principle can apply to software design. Even though software size is rarely a limitation these days, our mind is quite limited in [...]

[...] podcast and is covered there. We are writing this task manager as an exercise in software design and a few specific design patterns and approaches: event sourcing; command-query [...]

[...] server; where possible, discard server-side command handlers and host aggregate logic directly in Web UI. One of these initial steps involves replication of events from production event store to new [...]

[...] server; where possible, discard server-side command handlers and host aggregate logic directly in Web UI. One of these initial steps involves replication of events from production event store to new [...]

[...] push them to all subscribers Windows Azure to host backend workers and frontend ASP.NET MVC 4 for Web UI [...]

[...] would need a way to send commands (rename user) or report events (user logged into the web UI). Obviously, these would go to the same "command router" or "event recorder" [...]

[...] can be plugged internally). All of a sudden, this: reduces software complexity (e.g.: your backend server is only accepts one-way commands in JSON over HTTP and publishes events as JSON entities in [...]

[...] can be plugged internally). All of a sudden, this: reduces software complexity (e.g.: your backend server is only accepts one-way commands in JSON over HTTP and publishes events as JSON entities in [...]

[...] more monolithic, where it was absolutely necessary). Still the result is quite nice: 13 backend components which have on average 4-5 classes and the same number of public methods; 2 thin UI [...]

[...] more monolithic, where it was absolutely necessary). Still the result is quite nice: 13 backend components which have on average 4-5 classes and the same number of public methods; 2 thin UI [...]

[...] more monolithic, where it was absolutely necessary). Still the result is quite nice: 13 backend components which have on average 4-5 classes and the same number of public methods; 2 thin UI [...]

[...] . Making software free is easy. Making software usable without support is much harder. So Lokad developers had to create complicated heuristics to help customers deal with the problems. TSV parsing [...]

[...] . Making software free is easy. Making software usable without support is much harder. So Lokad developers had to create complicated heuristics to help customers deal with the problems. TSV parsing [...]