Caffeinated Wisdom

Most Domain Driven Design articles and books teach you to develop your business logic in such a way that there is no trace of a database or other dependency that would make your business logic (also known as Core code or Domain Logic) impure. That is great advice if you are developing your core business logic in a programming language that is not SQL . But what if all you know if SQL or SQL is your strong skill? The answer is yes, you can develop your domain logic in SQL in a domain driven way, if you try to adhere to the spirit of the DDD concepts. Objects or Tables? One of the main arguments for developing Domain Logic in Object-Oriented languages is that “real” world things are objects and thus is easier to model those real-world things in classes. But if you are in an organization and you start talking to Business Units about the logic they need, you would find that the concept of “spread sheets” are actually very familiar to them. It is so familiar, that countless of Business Unit

HTTP-based APIs have become a very popular way of exposing functionality to external entities outside an organization. For example, in order to support certain features of their products, some Vendors require integrating with your data real-time by calling HTTP APIs to get the information they need. Or maybe you have a very tech-savy customer that would like to get their data via APIs your organization exposes. Typically, a Development Team spins up those APIs using programming languages and platforms such as .NET and Java. But what if your organization only has Microsoft SQL developers? In this series of posts, I would like to propose that they are able to encapsulate the needed logic into T-SQL stored procedures and/or views without the need of the work of a typical development team. This is great for those “multiple hats” DBAs who might not be strong enough in regular languages, but with good enough skills to do some basic managing in Azure. Here is an overview of the process: Desig

How can you allow a Business User to maintain the business logic of your application? If your business users are Excel-savvy (as much business users are), then you could use Microsoft’s Graph API to access and run the logic within those Excel workbooks ( workbook resource type - Microsoft Graph v1.0 | Microsoft Learn ). This is not the OLE Automation of years past. We are talking about calling an HTTP based API. The approach is simple, from the business user side: Have the business users create the workbook and adjust it so that it performs the business rules it needs. They can designate some of the cells to be used as the “parameters” for the business logic. For example, given the values of cells A2 and B2 , run a series of formula calculations whose final result is in cell B30 . Save the excel workbook in a folder in your business’ OneDrive. Then, from your application code, make a series of HTTP calls to the MS Graph API: Get the Auth Token Call the createSession endpoint to creat

Sql Server Database projects are a great way to define your database structure and keep in in source control. Instead of maintaining a large list of migration scripts, you can instead define your database declaratively in the Sql Project as if you were creating a .net solution. This project style also facilitates the publishing of changes to Sql Servers. The publish process automatically detects what needs to change and creates the necessary Sql code to perform those changes. One of the challenges of using Sql Server Database projects is to include the Sql Project in your CI/CD pipeline so that it can automatically publish the changes to a Sql Server. Microsoft has migrated the Sql Server Database project format to the new “SDK style” project (introduced by .NET core). A generic way to integrate it is to call the commands from the command line as most CI/CD pipelines support some sort of command line invocation. The steps to run from the pipeline are: Build the project so that it gener