Filed under: Remote, Technical — Dave Sammut @ 1:19 pm
Implementing Domain Driven Design: Domain Diagrams – Dave Sammut
My team and I just completed a project where I believe that our knowledge of domain-driven design allowed us to complete an application based on a rigid framework with an aggressive time-to-market deadline. Unlike other web-applications we have made for the same parent project, this sub-site had a complex content model complimented with complicated business logic. The rigid framework we had to use had many page components with a long list of super classes which hindered any approach to a test-driven application development as the domain items (the business logic) was tightly coupled with the framework’s core architecture.
In this post I would like to show how the usage of Domain-Driven Design (DDD) allowed us to achieve our business goals.
At the beginning of the project, we received a set of documents that expressed the main business logic and the Information Architecture (IA). However, when we started to dig into these documents, we found inconsistencies with the business logic and the way different terms were used. In other words, there was no common vocabulary or agreement on business reasons for the requested business objects.
Having used DDD in previous projects, I took a stab at introducing my understanding of the application domain through the use of numerous diagrams. By application domain I mean the business logic, content models, object relationships, constraints, etc.
The introduction of a new process is always met with resistance and none was spared here. However, the diagrams sparked discussions and increased communication between myself, the technical architect and the business analysts. Through this process the I attained a deeper insight in the complex application domain which allowed me to improve the diagrams.
The domain diagrams became the necessary bridge between the business and technical people. Through the domain diagrams and their explanation, I could easily share the domain knowledge I gained while at the same time provided an easy reference for both technical and business staff.
Through the domain diagrams we manage to achieve:
- Created a common vocabulary for use by both the technical and business people,
- A deeper insight in the domain by the technical team,
- The discussions created a feedback loop through which technical limitations updated certain business assumptions,
- We established a better relationship between the business and technical teams which were located at separate locations, and this resulted in
- A shared ownership of the domain which increased team commitment and team optimism for a successful project.
Once the domain was understood by the technical team, a domain modeling session ensued which allowed us to achieve many technical goals and will be posted soon
Filed under: Remote — Dave Sammut @ 12:15 pm
Certain themes become cardinal rules after getting through a year long agile project working on a proprietary framework from within a near-shore development team.
As happens with many lessons learned, there are weaknesses exposed and praise for what worked well. As also happens with lessons learned, much of these are forgotten or simply not put into action during the next endeavor. So here are some key points, cardinal rules if you will, and awareness of potential pitfalls awaiting a remotely located development team - Dave Sammut.
“No Surprises” - Radiohead
The importance of regular code reviews which include pattern usage, best practices, performance and stability. This could possibly include participation of a non-team member to participate during the sprint to audit code and provide feedback back into the team during the stabilizing period.
Pattern Usage - The use of standardized techniques to perform both application specific logic (business logic) and pluming (retrieving data, URL creation) processing.
Best Practices - Javadoc, formatting, common java best practices
Performance - Policy counts, performance analysis which feeds back into application specific (business logic) patterns used. Perhaps an IA/BA review needed
Stability – Unit test coverage, Integration test coverage based on user stories
“I believe the children are our future Teach them well and let them lead the way” - Whitney Houston
In any discipline, be it technical, BA, IA or testing it takes an individual with the right attitude and approach to ensure quality and success (knowing what to deliver) upon which management would like to model new people entering a similar role. The problem is what when a new individual enters the role, new attitudes and approaches (including new good and bad habits) are introduced which at times are not part of the ‘modeling’ result management desired. However, without diluting an individual’s personality, a suite of cardinal rules (a manifesto even) should be communicated to ensure that no matter what good or bad habits are introduced, the core basics which define success are ALWAYS adhered to. Failure to do so simply reflects an ill placed individual in a particular role.
“A wicked messenger falleth into mischief: but a faithful ambassador is health.” – The Bible
At each location daily communication is paramount to resolving issues and to gain further insight into the domain, which is then reflected in the code-base, an updated IA or business rule. This will then need to be communicated to the testing team to ensure verification integrity. Further insight into the domain is achieved when concise and efficient communication, through the use of a common vocabulary, proper tools and domain diagrams, is exercised.
Communication across geographically separate locations presents increased risks of miscommunication. When ill communicated (misinformation) solutions are implemented (code, IA, BA) the actual results of the ill communicated solutions will surface at a later date when the issue in question is no longer fresh in all the participants’ heads.
To minimize the risk of miscommunication, an ‘ambassador’ at each location should be responsible for the quality of communication, through the use of appropriate tools (IM, phone, WebX), discipline in communication (common vocabulary) and with the help of visual aids (domain diagrams) to further drive an idea home. It’s not that only one person is involved in all communication, rather the ambassador should be aware of the big picture and be able to assist team members be good communicators.
“Necessity is the mother of all invention” - Thorstein Veblen
From the moment an idea is endorsed and selected as a user story the detailed definition is produced. This includes everything a development team needs to successfully implement a user story; design, IA, BA, user cases and test cases. Some user stories require a great deal of detail depending on its nature, others require very little definition at all, or at least very little of a particular artifact. The idea is to have ‘enough’ information for the successful development of the user story. However, should further insight be required, other artifacts can indeed be created to explain the further insight needed. Using a guideline as to what is indeed ‘enough’ and further artifacts delivered upon request minimizes the amount of decay and unused efforts. Once again, depending on the nature of the user story, the teams should agree to what degree is indeed acceptable amount of information. Failure to understand what “sufficient information” is can lead the design effort to resemble that of RUP with a heavy up-front design phase.
“I see dead people.” - Cole Sear (6th Sense)
The importance of communication amongst team members and in artifacts is a paramount theme when working in geographically separated locations. Without the luxury of face-to-face communication that benefits from being within an earshot or ‘around the corner’, team members must turn to alternative ways to efficiently and accurately communicate with each other.
With face-to-face communication the talker and the listener benefit from gestures, white boards (physical and air), body language and instance acknowledgment of statements, ideas and arguments. When separated, team members need to heighten their other senses to ensure that they make up for the lack of face-to-face communication. Team members need to be made aware of what tools are available and how to effectively communicate across these channels. These channels require that communication etiquette be adhered to minimize frustration and promote such tools.
“Surround yourself with the best people you can find, delegate authority, and don’t interfere as long as the policy you’ve decided upon is being carried out.” - Ronald Reagan
It’s impossible or very tiresome exercise to micromanage every deliverable of every team member. Each team contains different tasks, different skill-sets, different people with different ambitions with whom all tasks must be addressed. Each team member can indeed be strategically positioned to exploit their skill-set and can be used to attain new skills from different members performing different tasks. The art of cross-pollination ensures that no one person holds the information by which in their absence the team is presented with an impediment. This coupled with strategically positioning team members in roles which exploit their skills will create a well-balanced team and a skill-building team culture.
“Individual commitment to a group effort - that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi
On the whole the project is seen a one team divided into separate sub-teams which are all required to deliver artifacts (deliverables). Each team in this configuration can also be divided into other sub-teams. So, essentially there are two configurations which need to be addressed to minimize risks such as miscommunication and poor quality of work.
The two sub-team configurations:
- Co-located
- Distributed
Co-located sub-team
Co-located teams benefit from ease of communication amongst themselves to collaboratively produce their deliverables. The challenge such a team has is that of producing deliverables which concisely communicate sufficient information for other teams to use to fulfill the production of their deliverables. The risks the team has to deal with are indeed producing ‘just enough’ of information for other teams. Should another team require further insight, this request should be handled by the co-located team and addition information supplied to address any shortage of information. Basic rule is to know what exactly to deliver by adhering to a set of cardinal rules/guidelines.
Distributed sub-team
Distributed sub-teams have the same responsibilities as co-located teams with the additional challenge of team members located at separate locations. This adds additional risks of miscommunication of ideas finding their way into the final product thus resulting in a deliverable of poor quality. Such teams must establish efficient means of internal communication and an appropriate quality assurance measures.
No matter the configuration of a team, miscommunication (resulting in poor quality deliverables) can find its way into any facet of the deliverable. The only difference is that the less importance given to communication in either team will have different severity levels of repercussions.
Team Audits
Each team, regardless of discipline should be subject to regular audits on all deliverables from the different target audiences to ensure that the deliverable does indeed sufficiently communication clearly to all related parties. With additional efforts given to inspecting the quality of deliverables prior to their ‘sending off’ catch any potential issues before the producing team deems the deliverable to be ‘done’.