Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.
Related
I'm look for some guidance or best practise for how to configure and structure an Application which conforms to Hexagonal architecture that supports multiple (driver) adapters simultaneously.
My API / Application Layer / Ports represent the boundary of the Application. I am now writing the driver adapters, with the goal that the application supports both a console / CLI adapter and REST adapter in tandem.
Does anyone have any thoughts on approaches to the Main Component that configures and wires the application together?
A single Main Component that configures the full application: including all primary adapters. Along with loading the application configuration. In this case it would start the REST services and start the CLI console app.
A separate Main Component for each type of Primary adapter. ie. One for the REST application. One for the CLI / Console application. My concern is will result in a lot of duplication for configuring the Application within the boundary (ie. the API Services, Repositories, etc etc).
Follow the above approach but extract the common configuration / wiring into a shared class.
If anyone has any examples they could share that would be interesting to see.
Cheers,
Steve
This is an interesting question.
From my point of view, trying to be faithful to the pattern explained by its author, although it would also be posible to run more than one driver adapter for one driver port, the "app as a whole" (let's call it system, since the app is the hexagon) is an instance of a driver adapter running on each driver port of the hexagon, and a driven adapter implementing each driven port.
The configuration of the system is the adapter to select for each port. When you run the main component, you have to specify which adapter you want for every port.
That said, I studied two approaches in order to run the system:
(1) To have an additional component (name it main component, composition root, startup, init, or whatever you want) that instantiates the driven adapters and the hexagon, and finally instantiate the driver adapters and run them. This way, the system architecture would look like an app container in the driver side, and a plugin architecture in the driven side.
(2) To run each driver adapter on its own. It is the driver adapter that starts the game, asking the hexagon for a driver port instance, and the hexagon would ask every driven port for a driven adapter instance.
So to your question about the main component in your example, according to my approach (1), I would have two hexagon instances running, but you could have just one, I don't see any problem on that.
I wrote a theorical article about hexagonal architecture at https://softwarecampament.wordpress.com/portsadapters/ , and now I'm working on an article about how to implement hexagonal architecture, and a code example.
is there any code or docs about implement asp identity in clean architecture and how to apply CRUD operation in Application Layer with User Entity that inherit from IdentityUser in Domain Layer
I implement Asp identity in Domain Layer any ideas ??
I forget to mention that I use CQRS in Application layer
Here is a nice article provinding a lot of information on how to implement a clean architecture using DDD TDD and Identity.
Hope it covers your needs.
We have an application that is heavily used. In this application we have business logic in our viewmodels and in the service layer
Now we need to migrate the app to html because of performance issues, plus considering that Microsoft throw out the support for this technology.
We can't just stop the application for several months to finish it's migration. Our clients needs to use it. My first approach will be to migrate all the business logic to the services, making the app a thin client, so we can later use the services for ayax calls in a new ui, made with html
Do you have any experience with this migrations? What are the pros and cons?
We are currently doing one of these projects
what I would recommend is following
Have all business logic that aren't UI specific or silverlight specific in its own Business Libraries.
Put a service layer WCF or WebAPI (REST) on top of the Business logic so all the business logic can be accessed via different technologies
Use AngularJS or ASP.NET MVC + AngularJS combination so you can keep MV* pattern going and most probably use most of your ViewModel logic with bit change while giving some what similar experience to customers that are used to silverlight UI
1 and 2 was very important in our project because it gave that clean separation and flexibility to expand to any client machine without changing minimum code. Ex: later if we decided to make an Android app you just have to transfer only viewmodel logic without touching your business logic or services.
I am starting research on how to implement Node.js SOA (service oriented architecture) with JSON web-services.
As a small sub-question, I need an approach/framework/system to make universal configuration center for all companies web-services. So that we don't configure every application with exact address of other application, but just link to some central server to get that information.
(This should be very well worked-out topic for XML-based services, so some terminology/approaches/etc could/should be borrowed.)
Related to
RESTful JSON based SOA Registry
Service Oriented Architecture suggestions
UPDATE: This questions is about web-services configuration & orchestration.
GO for an active(having activity happening off late) framework with lean architecture.There's one called Geddy and another called Restify. If in doubt, Express can also be used for building webservices with JSON.
You can work on reading the centrally stored config from different app codebse when you use any of these.
It's confusing to categorize something into a model, and others into services. Is their any good thumb rule, help of which i may distinguish between a service and a model. I tried to look into various mvc docs, but almost all of them talk about model-view-and controller. Nothing about services.
Thanks
I would advise you to take a look at Robotlegs.
It is an ActionScript MVC(S) framework that promotes looser coupling between components, and has hooks to handle models and services accordingly.
Rules of thumb to distinguish whether to use a Service or a Model are described thoroughly in the documentation.
In short, a Service would be used to connect your application to the outside world, thus bringing external state into your application.
Whereas a Model would be used to store internal application state.
Robotlegs also features a handy IOC container.
You will be able to either implement your application with this framework or you could get a lot of ideas from looking at the framework code.
Check these out:
http://www.robotlegs.org/
http://www.robotlegs.org/diagram/