I wish to embark on a journey to discover new ways to build enterprise-ready on-premise web applications and services using ASP.NET Core version 1.1 and agile development practices, and I wish to take you along for the ride.
Let’s think for a moment about what is needed in almost every enterprise web service or web application (both technologically and philosophically):
- A reasonably consistent solution and project shell folder structure (facilitates pattern recognition among team members)
- Reusable code patterns for all application layers (Again, this helps to facilitate pattern recognition among team members. Also, we will attempt to follow SOLID principles)
- Application dependency management (for both server-side and client-side applications)
- Unit testing (when properly applying agile practices, this is not an option)
- Source code control and version history (a must for corporate compliance and to help developers maintain their sanity, and this should also include our database schemas and system configurations)
- Continuous integration builds and release processes (CI practices offer development teams a quick win that saves developers a significant amount of time, thus enabling them to focus on new feature development)
- Code reuse versus distributable components (when and where each makes sense)
- Dependency injection (to simplify composition and better support unit testing)
- Application configuration capabilities per environment (with or without a release management tool)
- Information and error logging (Event Log, Log Files, others?)
- Routing for both web services and web application views
- Restful web service design patterns (learn the verbs and nuanced ways to specify URL paths and query data)
- Data storage and retrieval mechanisms (Relational, non-relational, and in-memory data stores)
- Data access design patterns (ORM, SQL, etc.)
- Generation and management of test data for unit and integration tests
- Web service API management and cataloging (learn and control who’s using your services, how much they use them, and get a little swagger in your swashbuckling steps)
- Specifying who is authorized to use your web services and web applications
- Authenticating users with single sign-on using OAuth2 (or SAML2)
- Web Service integration patterns (message queues, data pumps, publish/subscribe, interface engines, restful clients, etc.)
- Microservices (what are they, why is there so much confusion about them, yes we can start building them now, containers are not required to gain the benefits of these design patterns)
- Data migration among environments (even if you did not realize you were missing this capability)
- Monitoring of both web applications and web services for uptime and accessibility
- Deploy new code on any day of the week at any time of the day (yes, this is actually possible)
- HATEOAS (Hypermedia as the Engine of Application State) is a constraint of the REST application architecture. A hypermedia-driven site provides information to navigate the site’s REST interfaces dynamically by including hypermedia links within the responses. (This would make our web services more business user-friendly.)
- Hopefully, we’ll get into the cloud someday
- Others? TBD
Throughout this journey, I will do my best to apply SOLID principles to my designs. What are SOLID principles?
(S) Single responsibility principle – a class should have only a single responsibility (i.e. only one potential change in the software’s specification should be able to affect the specification of the class)
(O) Open/closed principle – Software entities … should be open for extension, but closed for modification.
(L) Liskov substitution principle – Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
(I) Interface segregation principle – Many client-specific interfaces are better than one general-purpose interface.
(D) Dependency inversion principle – one should depend upon abstractions, not concretions.
One of the primary goals I wish to achieve is how terse can I write code to fulfill a given implementation need to provide simplified and meaningful patterns to share with my peer corporate developers. The design decisions I make along the way will likely go against the grain and sensibilities of many software architects and developers whom will have strong opinions based on their career experiences using well-known conventions and patterns. Also, since it is not always possible to make everything “simple”, sometimes greater complexity will be required in my designs despite my best efforts to make them simple.
The primary motivating factor driving my current quest is that my employer (a mid-sized organization with about 700 IT staff) is finally on the path to pursuing agile methodologies and newer SOA architecture practices. So, I believe we must adopt new thinking in our approach to how we do just about everything. My upcoming blog posts (tutorials) will be a series of exploratory ideas that I wish to share not only with my co-workers but also with the larger community of peer software architects and developers, as well.
So, shall we get started on this journey together? Yes? Excellent!
OK, so you have already installed the Current .NET Core SDK version 1.1, correct? If not, please read and perform the steps in my blog post called: Install Developer Tools For ASP.NET Core.
Please stay tuned for what comes next…