How does your team approach software development? I am talking about planning and direction prior to opening their development environment to write code.
I see 3 general archictecture styles in use. Some teams will mix styles but here are the three I have run into during 24 years of professional software development
Domain first (business domain driven)
Resources for more learning:
https://www.idesign.net/Books/Righting-Software slightly different from domain driven design but there are some overlaps. IDesign focuses on areas of volatility(most likely to change). Many of these changes are due to business related changes so there is some overlap. I hightly recommend the bood "Righting Software".
pros | Requires thougthful,holistic design. When new customer requirements occur the team decides how to on whether to incorporate the new need. Instead of reactively "shoe horning" or "tacking on" the emerging need. The team decides how to incorporate the requirements into the current domain objects or should the team just say "no" or "not now". When the data needing returned needs to be modified often a change to the UI or backend code is not necessary so deployment related to changes may be easier in some cases. |
cons | More thinking is required around the domain object that the code will be built around. An additional "con" is few development shops use this approach. The approach is very different than the more immediately tactical approaches like the database driven approach and the customer need driven approach. |
Database Driven
In my experience many projects are a hybrid between some domain obects though not well defined and database centric (CRUD) create, read, update delete. These applications often present user interfaces for creating, updating, and reporting on data. This approach is very pragmatic and often used in internal business applications where they solve a very specific proplem for a very specific set of users.
I would say much of the code that runs business is created and continues to use this approach.
When new features needed, discussions surround various means of accessing the database, various flavors of ORMS(object relational mappers), stored procedures, reporting tools. Some teams favor using stored procedures instead of object relational mappers. As a side note you can execute stored procedures with many ORMs.
Some teams design the database first then design the software. Some teams interactively create new features then design the database to accomdate the customer needs that are being addressed by new features.
This approach is very tactical and in my opinion delivers the fastest results (fast is not always better).
Resources for more learning:
pros | Work can be divided among team members between database tasks and coding tasks. When using a stored procedure as a source for code in the UI, the code is in one place, backed up, and the database server can choose an execution plan on the fly that is most efficient based on server activity. |
cons | When using object relational mappers there is a possibility that developers are allowing the ORM to execute ineffecient code. With skill many of the problems with ORMs can be alleviated but there are times when a stored procedure will be more efficient. One more downside is that most developers have strong opinions about data access and database administrators also have a stake in performance. In my experience there are varying opinions and the person on a team with the most influence wins. |
Reactionary Chaos Driven Development
I often call this chaos driven development. Perhaps a company has one customer with a very specific need. The go to behavior is to satisy the customer need as quick as possible. This often means forks in the flow of the code so the specific customer gets their needs met. The problem with this is at a later point another customer has a similar need. The tendency is to place another fork in the code. The complexity increases. Some team members may request refactoring the code but this will take time, the customer needs this now. Had the team decided to plan how a feature could be used by multiple customers earlier they would not need a duct tape solution.
pros | Specifically addresses the customer needs, tactical, less gold plating. Customers don't have to wait on a design change that incorporates their change. |
cons | Can result in difficult to maintain code as time passes. Changes frequently break existing code, often in unexpected ways. This type of code base frequently has little or no tests. |
Resources
As a developer the most efficient and satisfying project I have worked has had an architect that advocated for a more holistic design that anticipates areas of the system that will change frequently and domain objects, and language was designed around this approach.
I prefer thinking of the domain first but have most of my experience focused on database focused architecture. Architecture that is only based on the problem domain or task based the hardest to grow since the decisions are based of problems or customer customizations at a point in time, as time passes the code becomes less and less coherent, difficult to maintain, update, test, release.