Domain Driven Design, Software, Team

Software Development – Domain Drive Design

I bought a book about DDD (Domain Driven Design). It’s about this software development methodology. It seems pretty interesting. I’m still at the beginning what I have understood is that developers should work alongside domain experts. This allows developers to distil knowledge from domain information to build a model. This model will be used in software prototyping and/or implementation. This implementation lets refining the model through domain experts’ feedback. The refinement triggers software modification so we can iterate through this process. All the process allows improved models where terminology is always more defined between domain experts and developers that will be used for significant improvements.

Important elements of the process are continuous learning and prototyping/implementations. These allow developers by domain experts’ feedback to validate what they have learned about the domain. On another side they allow domain experts to learn about the rigorous world of software development.

A key principle of DDD is that developers must learn about the domain by working alongside the domain experts that learn about software modelization.

So, what I think, and this is my personal conclusion, is that developers should care about their products and stakeholders. They cannot think to do only technical knowledge acquisition, or get the knowledge of the domain only from the analysts. They cannot ignore the domain. They must have a knowledge of the model as clear as possible.

Advertisement
Standard
Software, Testing

Building a Complete Testing Framework

In the software lifecycle, building a test is an essential framework to enable trust in our system. It allows to pop errors out before the product goes into production.

So if you have extensive coverage of your code you can be assured with certain reliability that your code is flawless.

But an automatic testing framework is not enough alone. Before we put things in production we need to test manually in a staging environment. So automatic tests are necessary but are not enough.

Surely, we can rely on End-to-end tests but they are hard to write and not so easy to maintain and, in the end, nothing can substitute a good human eye that makes an overall test about the new feature and checks if the system still works properly in staging and production environment.

Besides, collecting the issues from the final users is the best test an application could have, because only when the application is used by whom is supposed to be used that we can check if, overall, we have done good work. And at the final instance, if our product satisfied end-user expectations and needs.

Standard