In part 2, I talked about my domain modeling thought process so this post is about trying to persist those objects for long term storage. Although the avenue for different data storage provider is always open with the kind of…
Artineering
art and engineering of software
Blog Archives
Building Domain Driven Architecture in .NET – Part 3 (Repository Design)
Tagged with: aggregates, architecture, AsynchronousProgramming, C#, design, design patterns, domain driven design, domain modeling, onion ring architecture, Performance, programming, repository pattern, software, software architecture, software development, software engineering, technology
Posted in API, architecture, design, best practices, domain driven design, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
Posted in API, architecture, design, best practices, domain driven design, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
Building Domain Driven Architecture in .NET – Part 5 (ASP.NET Core App)
In part 4, I detailed the way I went about creating application services for my expense tracking application. In this final post, I will talk about the ASP.NET Core MVC application that I built with HTML5/Razor front end views on…
Tagged with: .NET, .NET Core, architecture, ASP.NET Core, asp.net mvc, asynchronous programming, C#, decoupling, dependency injection, design, design patterns, domain driven architecture, domain driven architecture in .net, domain driven design, JavaScript, kestrel, Microsoft Azure, open source, programming, software, software architecture, software development, software engineering, task based asynchronous pattern, technology, Usability, web applications
Posted in API, architecture, design, ASP.NET Core, domain driven design, Microsoft Azure, refactoring, software architecture, SOLID principles, Uncategorized
Posted in API, architecture, design, ASP.NET Core, domain driven design, Microsoft Azure, refactoring, software architecture, SOLID principles, Uncategorized
Building Domain Driven Architecture in .NET – Part 4 (Application Services)
Application services can be loosely compared with the business logic layer of the yesteryear with one key difference, application services don’t actually contain any business logic neither they enforce any business logic.
Tagged with: .NET, application architecture, application services, architectural styles, architecture, asynchronous programming, building domain driven architecture, building domain driven architecture in .net, C#, command and query responsibility segregation, Command Pattern, CQRS, data transfer objects, decoupling, design, design patterns, domain driven architecture, domain driven design, DTO, implementation, programming, RESTful, scalable application architecture, software, software architecture, software development, software engineering
Posted in API, architecture, design, ASP.NET Core, best practices, domain driven design, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
Posted in API, architecture, design, ASP.NET Core, best practices, domain driven design, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
Building Domain Driven Architecture in .NET – Part 2 (Domain Modeling)
In this post, I will be going over the domain modeling in a bit more detail in terms of its design and show my thought process and the decisions I made and why I made them.
Tagged with: .NET, architecture, C#, design, design patterns, domain driven design, domain events, domain modeling, domain services, object oriented design, object oriented programming, programming, software, software architecture, software development, SOLID principles
Posted in API, architecture, design, best practices, domain driven design, refactoring, software architecture, SOLID principles, Uncategorized
Posted in API, architecture, design, best practices, domain driven design, refactoring, software architecture, SOLID principles, Uncategorized
Building Domain Driven Architecture in .NET – Part 1 (Overview)
Having read Vaugh Vernon’s book on DDD implementation, I decided to portgrade (port+upgrade) my old clunky Windows based N-tier desktop expense tracking application to ASP.NET Core MVC application using some of the Domain Driven Design concepts I studied in the book.
Tagged with: API, application services, architecture, ASP.NET Core, asp.net mvc, autofac, dependency inversion, design, design patterns, domain driven design, domain modeling, entity framework core, hexagonal architecture, integration testing, inversion of control, layered architecture, Martin Fowler, ninject, onion ring architecture, part 1, persistance agnosticism, programming, RESTful, software, software architecture, software engineering, SOLID principles, technology, test driven development, unit testing
Posted in architecture, design, domain driven design, refactoring, software architecture, SOLID principles, Uncategorized
Posted in architecture, design, domain driven design, refactoring, software architecture, SOLID principles, Uncategorized
Implementing Generic Repositories in Quasi-DDD Applications
Over the last several weeks I have been working to build a basic re-usable CRUD type repository interface useful for anemic CRUD domain models but that allows for extensions that can potentially be used with richer domain models like the…
Tagged with: .NET, .NET Core, architecture, ASP.NET Core, C#, CRUD, design, design patterns, domain driven design, entity framework core, generics, implementation, Performance, programming, repository pattern, software, software architecture, software development, SOLID principles, technology, unit of work
Posted in API, architecture, design, ASP.NET Core, best practices, domain driven design, Over Engineering, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
Posted in API, architecture, design, ASP.NET Core, best practices, domain driven design, Over Engineering, refactoring, software architecture, SOLID, SOLID principles, Uncategorized
You Ain’t Gonna Need That API
If you are not sure who this API is going to benefit and how, chances are You Ain’t Gonna Need It
Tagged with: .NET, API, architecture, Azure, Azure REST APIs, Azure SDK, Azure WebJobs, C#, design, KISS, modularisation, Over Engineering, programming, Queue Storage, RESTful, software, software architecture, software development, software engineering, SOLID principles, technology, uncle bob, Usability, visual studio 2015, WebJobs, YAGNI
Posted in API, architecture, design, Azure Storage SDK, Microsoft Azure, Over Engineering, refactoring, RESTful, SOLID, SOLID principles, Uncategorized
Posted in API, architecture, design, Azure Storage SDK, Microsoft Azure, Over Engineering, refactoring, RESTful, SOLID, SOLID principles, Uncategorized
