Displaying items by tag: domain driven design

The first video of our CodeBot 201 tutorial series walks you through defining a domain model for a Fantasy Football app, and using CodeBot to instantly transform the domain model into a complete MongoDB database and REST API:

How easy is it to generate a working database and API from an EA domain model?  Really, really easy...

This video will show you how in less than 3 minutes…which is about how long it takes for you to try it yourself.  In our example, your app can show video of the players scoring touchdowns in near real-time 

In this video we’ll follow the evolution of the TEAM object from a noun on a short problem domain description,

Team is an object in the problem domain

 to a class on a domain model diagram,

A Team has an Owner and a Roster and a Schedule

to a Mongo DB collection with a NodeJS REST API (documented in Swagger),

Use the API to Create Teams, Read Teams, Update Teams…

and a client-side layer that makes accessing the API nice and straightforward.

 You don’t need to call the API directly because CodeBot generates client-side code including usage samples

CodeBot is a complex product that does an incredible amount of work to simplify your life as a developer. Give it a try today!

One of our biggest challenges at Parallel Agile is explaining how two apparently unrelated aspects of our business are actually very closely related. Specifically, how our domain driven database and API generator (aka Parallel Agile CodeBot) enables the Parallel Agile Process, which allows large teams of developers to collaborate more efficiently and breaks the “two pizza rule” on team size.

To understand how the CodeBot enables large-scale parallel development we need to go back to Brooks’ Law, the widely believed postulate that you can’t accelerate a software project by throwing more developers at it. Fred Brooks identified some key reasons why this has been (for the most part) a truism for the last 50 years. Two of the most important reasons are:

1) Communication. When you add new developers to a software project, somebody has to explain to them how the existing code is structured, and the new developers each have to experience a learning curve before they can be productive. Generally it’s the experienced developers (who are already productive) that have to take time away from their own work to train the new folks. So adding developers can actually slow you down.

2) Integration. If you have a large team of developers working (relatively) independently, it’s going to be difficult to make all of the pieces plug together and play well as an integrated whole piece of software.

It’s important to remember that Fred Brooks developed his postulate while managing a large mainframe operating project (OS/360), which was introduced in 1964. That’s a long time ago. There were no UML modeling tools, no REST APIs, no NoSQL databases. So it’s not unreasonable to ask the question 55 years later whether any modern technical innovations might mitigate some of the underlying factors that have made Brooks’ Law seem to be inviolable for such a long time. That answer turns out to be Yes – making a domain model executable mitigates both the communication and integration problems and enables large-team development to work a lot better.

While I’ve never been a big fan of Brooks’ Law, when we started the research that led to Parallel Agile, there was no particular intent of trying to disprove it.  It started back in 2014  when Barry Boehm and Supannika Mobasser invited me to give a guest lecture on ICONIX Process in their  CS577 Software Engineering class at the University of Southern California.   Around this time I had developed an interest in geofencing, and had in mind to develop a geofenced mobile app that delivered coupons to your phone when you got physically close to the business that was offering the coupons. 

When I accepted the invitation to guest lecture I decided to ask if they would like me to grade a couple of UML homework assignments in addition to guest lecturing. They agreed so I split my Location Based Advertising project into 47 low level use cases and assigned one use case per student as homework (writing prototype code for the use case was optional extra credit).

To make a long story short, we were all surprised that the 47 independently developed use cases actually integrated into a cohesive system. I can clearly recall sitting in Barry’s office saying “you know, that’s not supposed to be possible” and Barry agreeing “yes, I know”. When we started investigating how the successful integration happened it seemed that we had made some fortunate choices of using a NoSQL database (Cassandra) and a REST API (Node JS), and giving all the students a code template that implemented the database access functions (aka CRUD functions) for a Cassandra collection that they could clone for their part of the database.

It turned out that having the domain model in place made communication across the large (47 student) team go pretty well, and having all of the database access functions available through a REST API allowed different pieces of the system (iOS app, Android app, web app) to integrate together with ease.  And when we studied the effort numbers it turned out that each of the 47 use cases took about 4 days to develop – a day on requirements analysis, a day on design, and two days of coding.

One of the student from that project joined the PhD program and implemented a code generator that turned domain models into Mongo DB and Node JS, and after using this successfully on several other projects we decided to start Parallel Agile.

So, to sum it up…having a visual model of the problem domain makes it easy for everybody to get on the same page about what’s being built.  Generating your database from this domain model, and having a uniform set of functions to Create, Read, Update and Delete items in the database makes it easy for everybody’s code to integrate together.  And that’s how a code generator enables large-scale parallel development.

This article will introduce you to both the Parallel Agile (PA) process and to the Parallel Agile Add-in for Enterprise Architect, which enables the PA process for Sparx customers.

Download the article in PDF here.

The Parallel Agile Add-in generates database access code and REST APIs from domain models, and it works in conjunction with the ICONIX Agile DDT Add-in, which generates acceptance tests from requirements and use cases.   Both add-ins are free.

We’ll discuss:

• What’s Parallel Agile?
• Compressing schedules with parallel development
• Improving quality while compressing schedule
• Why did we build an Enterprise Architect Add-in?
• What’s an Executable Architecture?
• What’s a Parallel Agile CodeBot?
• Using the CodeBot to generate code for your domain model
• Using our Cloud-Based Hosting Service to Test Your Generated API
• Use Case Complexity Analyzer
• Parallel Agile MDG Technology - supports Sprint Plans