Same idea as last time -- except now with more awesome.
Schedule
6:00PM Doors are open, feel free to mingle
6:30 Presentation start (3 presentations, approximately 45minutes each, including questions)
9:00 Off to a nearby watering hole for a pint, food, and/or breakout discussions
Legacy Code: Using Domain Driven Design and Event Sourcing to Carve Out Areas of Sanity
--Â Robert Reppel
You...
[read more]
Same idea as last time -- except now with more awesome.
Schedule
6:00PM Doors are open, feel free to mingle
6:30 Presentation start (3 presentations, approximately 45minutes each, including questions)
9:00 Off to a nearby watering hole for a pint, food, and/or breakout discussions
Legacy Code: Using Domain Driven Design and Event Sourcing to Carve Out Areas of Sanity
--Â Robert Reppel
You read about Domain Driven Design, CQRS and Event Sourcing.
Monday morning you're back to fixing legacy code.
Now what?
âAutonomous Bubblesâ (http://www.domainlanguage.com/newsletter/2012-03/) Â can be part of a move towards Domain Driven Design and CQRS/Event Sourcing when surrounded by legacy applications. We'll see an example of how this strategy can be used when enhancing an existing system with new functionality.
Establish boundaries: We'll use the SOLID principles, business knowledge and Ubiquitous Language to determine where legacy code ends and the new implementation begins.
Implement new functionality, guided by tests. At this stage, we'll use event sourcing to ensurebetter testability and to provide a âsanity checkâ for dealing with dependencies between bubbleand legacy.
Establish  a synchronizing anticorruption layer to integrate with the legacy code.
This is a code-heavy session with examples in C#.
Data, Context, Interaction
--Â Chris Nicola
A common problem in designing systems using MVC architectures has been which objects should be responsible for encapsulating the rich behaviours of the domain. The principles of SOLID ask us to restrict our classes to a single responsibility, keep our system design modular, and at all cost, avoid the need to modify classes just to extend or add behaviour.
By itself, MVC largely fails to address many the principles of SOLID. For example, the common Rails practice of the "fat-model/thin-controller" is really only slightly better approach bloating both controller and the model. The bloated ActiveModel class is just a slightly more isolated rancid code smell.
DCI extends and complements MVC by advocating a composable domain behaviours organized by use cases. In DCI the  ActiveModel classes are generally "dumb" responsible solely for modelling and encapsulating the data structure. "Contexts" provide a representation of individual use cases of the system and serve to coordinate the interactions between the "roles" which extend the data classes with the rich behaviours representing the 'actors' within the interaction defined by the context.
DCI brings the principles of SOLID and domain-drive-design (DDD) back to MVC applications--though it can easily be applied outside of MVC--because as we all know, the only thing missing was yet another architecture acronym (YAAA!)
MIA: Monitoring, Instrumentation and (Log) Analysis
-- Sean Porter
Monitoring is important, as you can't manage what you haven't measured. There are several ways an application can emit and expose the data that we as developers and operators care about, the most common methods being log streams and instrumentation.
Logs can be a treasure trove of information, usually lightly structured, full of metrics, performance and usage indicators. Manual instrumentation is a necessary evil, providing a way to measure what code does when it runs, in production. Knowing application dependencies, understanding their relationships, and monitoring all the way down to the system resources they consume is a MUST. Nothing beats a functional check.Â
There is not one tool to rule them all, think unix toolchain; Logstash, Collectd, Sensu, Graphite, and Gdash. Visibility is important, dashboards are as good as the people watching them.
Demo stack included.
How to Contact Us / Re Comments
Please note any comments you add to this event (below) will be e-mailed to all members of the group. We're trying to avoid spamming the list, so please do not use comments for jokes, job postings, requests for help programming something or anything else off topic. If you have questions or need to contact us, use the 'contact us' link on the left. Thanks!