Today I spend 3 pomodoro *reading* a book written by the famous Dino Esposito on Modern Web Development. My main goal was not to get into the details of the technology but mainly to get an idea of the approaches in design and architecture. I like his style, pragmatic and to the point.
My main takeaway are:
- Design your API carefully. If a developer can use an API the wrong way, he will.
- Event storming is an effective approach to explore the business domain (Alberto Brandolini). It consists of getting developers and domain experts in a room together to ask questions and find answers.
- It is highly recommended to have an Application Layer that sits in between the presentation layer an the rest of the system. It is the part of the business logic that implements the workflows behind use-cases, orchestrates any tasks triggered by the presentation. The domain logic, conversely, is the part of the business logic that implements business rules that don’t vary according to use-cases. The domain logic is reusable across multiple presentation layers. The author tend to organize application layer methods in classes that go hand in hand with controller classes. The main benefit of having an application layer is keeping workflows distinct from business rules and domain-specific processes.
- There are two increasingly popular approaches to implement scalable websites:
- CQRS: You generally use a domain model only in the command stack. The query stack is made of plain data access code and use simple DTOs to bring data to the presentation layer.
- Event sourcing: You store events and, if required, you process events to extract projections of data that take snapshots of the current state of the system. An event is immutable, so logs of events can be applied with no risk of creating concurrency and synchronization issues.
- UX Driven Design: the author recommend a top-down approach in website development to emphasize the presentation layer and the actual screens the user will end up working with. Mobile users tend to have high expectations when they navigate to websites from their mobile devices.
- These days, what’s more important than knowing technology is knowing design and architecture patterns, best practices, and application solutions that have a successful record. The point today is no longer to use the latest release of the latest platform or framework. The point is just to give customers what they really want.
I fully agree with your closing point. Knowing the technologies and patterns is important, but is that the role of a developer or of the architect? Is the role of architect the inevitable destination for a developers career?
Do we get to a point where we stop looking at the language or technologies we are using, which we were once so passionate about, and instead look at the best tool for the job, then realise we are looking at a solution for the bigger picture, which is the role of the architect.
Great questions Karl and I don’t know the answers.
The architect role is very poorly defined and it is different in every company. I tend to prefer the combined approach. I believe the architect should still write code. At the end of the day, I don’t think I like the distinction as a job title. In a team, you might find more architecturally inclined people that lead system decision but ultimately is the all team that own the decisions and everyone can contribute. In Redgate we don’t have a defined architect role. We are all Software Engineers and it seems to work for us. I can understand needs are probably different in bigger companies where there is a lot more coordination between teams. I worked in a bigger company where the architects were very disconnected to the team, producing documents and despite I had great respect for their clear technical competency, I didn’t like it much.
I like .NET and Microsoft technologies. If I can solve the customers problems using my preferred tools I have no reasons to look at other solutions. Most of the time, my technology stack of choice is more than enough and the familiarity I have is a competitive edge. In my company, for example, we are very close to Microsoft and we mostly use .NET as it does not make sense to use other technologies for the sake of it. However, this does not mean that we don’t use other technologies if we need. I think is pragmatic to have a default choice and expand the search only if needed. Different technologies need to be learnt and it’s a cost for the team and the company. I don’t think making this decision is necessarily the role of the architect, I think is the role of the team to come up with the best technologies for the project.
How would you answer your questions?
The Architect is probably the most important role and even the smallest team (2 developers) will have an architect, even if they don’t realise it!
I believe that being an Architect isn’t about telling people how to do things, what language to use or producing documentation, it is about having the bigger vision on the technology in use and how the separate software will work together to form an overall product.
I think the Architect role comes with experience and only once you have used multiple languages on a variety of projects and systems will you be able to know what is a good design and what is a bad design. As the saying goes, books are OK, but there is no substitute for experience. How many times do we finish a project and then think that if we were to do it again, we would do it completely differently.
An Architect also has to keep up to date on technology, not to use the latest and greatest, but to make sure we use the right tool for the job. A new feature in Azure could give a new way to accomplish a task quickly, which previously took lots of effort.
For example, Web Jobs and the Azure Service Bus. Using these allows you to write small, individual Web Jobs to process messages in an efficient manner. this might have been cumbersome in a single larger application.