The Project Pattern
Each project seems to have a pattern. In the .NET world, we typically start with some form of MVC. If you're doing micro-services, then REST becomes a top-priority for the team to agree about. On some projects it's DDD. I feel like no matter the team or project the team gravitates toward establishing a pattern statement like:
We follow the ________ pattern on this project.
It's great to have a team talking patterns. Code is looking clean and organized, things are making sense to new the jr. devs. And they are looking up to mid- and sr. devs who are glad to answer the questions from their vast experience with _____ pattern. Those devs tell stories about it gone wrong, and experiences with teams that did it so much better than this team. The team boasts and prides itself on working this pattern.
These are good devs! This is a good team.
The Pattern is a problem
90% or more of all applications I have worked on use more than 1 pattern. The patterns cross each other, intersect and weave into the code. But there gets to be so much discussion about 1 pattern everything revolves around it. Other patterns are mere after-thoughts. Thus starts the problem...
An Example
The team that starts with MVC building a micro-services architecture which focused on REST endpoints has made everything REST-based. Each element has it's own endpoint supporting GET, POST, PUT, DELETE and the occasional PATCH for each and every object they encounter.
Their application is working with 50 requests to their micro-services per page view to build the up the view, and things start to get slow.
Someone suggests a cache service returning a "composite" object in 1 request to speed things up. It's micro-services, so why not add another query service to do just that? Excellent idea - the team just gave themselves the two hardest questions in computer science.
What they missed
So a new kid joins straight out of DDD training, and dares to ask "why didn't you use DDD and leverage a nice aggregate root". 99% of this code requests everything from these 2 roots, and performs actions aligned to these roots.
Of course, at this point the team quickly dismisses the notion because it's not the REST pattern that we have working. After all that's just how micro-services are supposed to be done.
Take-away
With any project, keep an open eye towards new patterns. Be astute and understand where different patterns are in the code.
This turns a good developer a GREAT developer.
Be constantly asking questions like this to yourself as you code.
- Is the JS-code following MVVM?
- Is there an aspect of code within that service layer that would benefit from a full DDD approach?
- Are repository patterns consistent, or would they just splitting up and confusing an aggregate root?
- Is there an n-Tier pattern and if used, how does our Unit-of-Work pattern work?
- Is State-Transfer REST the right thing for your application or would it be more logical to use a RPC-style method?
Note: this article on REST confusion is a great read, and covers more specific examples in detail.
Top comments (0)