I'm studying business layer and need a complete reference which covers issues about "how to manage dependency between business layer and other layers", "how many ways are there to send data between layers" and most important for me "how to group business logic and make business component and talk about possible ways....".
do you know any reference?
EDIT:
I would be delighted if you introduce some e-book for it.
Thank you
the best (in my opinion) approaches to decoupling layers it to use a message passing metaphor. This way communication between the layers is done with messages that are types that contain information only pertinent to the communication. These light weight types are then interpreted by each layer as they see fit.
In essence don't pass things that are not needed. If both layers need a piece of information then there is a high likely hood that some other entity should be brokering access to that information (for example persisted data in db).
I recently stumbled onto this one and found it to be a great read (free ebook in PDF, or read it in MSDN), got the printed version on Amazon shortly after.
Microsoft Patterns & Practices Application Architecture Guide 2.0 -
http://apparchguide.codeplex.com/
EDIT: Here's the section on Business Layers in the MSDN version: http://msdn.microsoft.com/en-us/library/ee658103%28v=PandP.10%29.aspx
I think you should consider reading these books.
(source: infibeam.com)
How about something like
Three-Layered Services Application
(source: microsoft.com)
and
Layered Application
Related
I am thinking what is the best way to structure your micro-services, in the past the team I was working with used Axon Framework and PostgreSQL and each microservice had its own event store in the PostgreSQL database, then we built communication between using REST.
I am thinking that it would be smarter to have all microservices talk to the same event store as we would be able to share events faster instead of rewriting the communication lines using REST.
The questions that follows from the backstory is:
What is the best practice for having an event store
Would each service have its own? Would they share the same eventstore?
Where would I find information to inspire and gather more answers? As searching the internet for best practices and how to structure the Event Store seems like searching for a needle in a haystack.
Bear in mind, the question stated is in no way aimed at Axon Framework, but more the general idea on building scalable and good code. As the applications would work with each own event store for write model and read models.
Thank you for reading and I wish you all the best
-- Me
I'd add a slightly different notion to Tore's response, although the mainline is identical to what I'm sharing here. So, I don't aim to overrule Tore, just hoping to provide additional insight.
If the (micro)services belong to the same Bounded Context, then they're allowed to "learn about each other's language."
This language thus includes the events these applications publish and store.
Whenever there's communication required between different Bounded Contexts, you'd separate the stores, as one context shouldn't be bothered by the specifics of another context.
Hence it is beneficial to deduce what services belong to which Bounded Context since that would dictate the required separation.
Axon aims to support this by allowing multiple contexts with the Axon Server, as you can read here.
It simply allows the registration of applications to specific contexts, within which it will completely separate all message streams (so commands, events, and queries) and the Event Store.
You can also set this up from scratch yourself, of course. Tore's recommendation of Kafka is what's used quite broadly for Event Streaming needs between applications. Honestly, any broadcast type of infrastructure suits event distribution, as that's how events are typically propagated.
You want to have one EventStore per service, just as you would want to have one relation database per service for a non EventSourced system.
Sharing a database/eventstore between services creates coupling and we have all learned the hard way that this is an anti-pattern today.
If you want to use a event log to share events across services, then Kafka is a popular choice.
Important to remember that you only do event-sourcing within a service bounded context.
I was going through design principles but could not understand this principle(avoid Micro layers), what would the significance be. I tried to google it but could not find any examples or explanation for this design principle. Could it possible for someone to explain this with example,what advantages it has in which scenarios? Does layering not localizes changes and reduces ripple effect of changes in software?
You’ve misinterpreted the way the principle is written. The author wasn’t trying to say “avoid micro services”. They were trying to say “When dealing with a micro service, don’t keep adding features or functionality to it. Instead, add an additional micro service to deliver the new functionality.”
The intent is to help you keep each micro service focused on a single task. This simplifies any system that depends on your service. And, it means you can more easily update your service — possibly by quickly rewriting it if you come up with a better performing design, for example. It’s hard to say “we’re going to rewrite our server” if that’s a six month task. It’s much easier when it’s only a one- or two-sprint task.
This thread needs a reboot coz of 2 reasons.
The Clean Code book that I have doesn't have a mention of Micro Layers. So not sure where the now "omni"-downloaded Clean Code cheat sheet got this from.
It would help if someone can guide me to where in the Clean Code book I can read on this one.
Am not fully satisfied that we re discussing Micro Layers in the scope of Micro Services. Bringing in an arch pattern Micro Services is not helping discuss a topic in a book that was written at a base level of Code and OOAD and a bit of design.
Instead for practical illustration purpose a code level example of the above statement is needed.
Where do utilities like database communication, cross-program communication, verifying model data, authorizing credentials and other utilities fit in the MVC/MVP pattern? Are they just independent members that communicate with the Model/Controller, or do they fit in the Model/Controller category?
it's depend of how you setup your project(s) and what framework(s) are you using. I have this blog post I used it as reference A Better Understanding Of MVC (Model-View-Controller) Thanks To Steven Neiland
hello again, WSO2 community.
My last question about your architecture for my research is not a technical question, but a future-oriented one instead.
I was thinking about the OSGi approach the Suite has, that is one of the most interesting abstract things about SOA in general and WSO2 in particular I have found. An OSGi is sure a puzzling puzzle.
Thinking about pieces connected together reminded me about Service Component Architecture: a mean to see all the pieces as a whole easier.
Well, my question, son of my thoughts, is: "Why not to enable SCA for WSO2, when all the pieces have Carbon as a common denominator?" Carbon seems to be a nice candidate to be SCA.
The architecture could have only one instance of Carbon underneath, and WSO2 components above. The user should be able to interact with Carbon through only one interface and see all the pieces and their installed feature.
Is it possible? If it's not, why?
I hope I've been of some use through all the way here, and I thank you for having accompanied me to the end of my journey!
I hope there will occasions to collaborate or simply sharing ideas again!
It is conceptually similar to what it does with OSGi and Endpoint References in Carbon App model. Possibly can look at SCA Assembly as an alternative wiring model.
Has anyone created an empty solution stack for .NET (C#) that incorporates an IoC framework for DI using multiple projects?
I've struggled for months to create a good reusable stack that has:
MVC UI web app
Empty BLL project (will add real entities later)
Empty DAL project (will add real daab classes later)
Reference/Search data tier
Includes an IoC framework
Sample usage of DI in a Home controller that can reach all the way to the DAL thru the entity layer or to ref/search tier all thru interfaces
Must NOT set a hard reference of any concrete classes at the UI layer
I've attempted this a few times but I always get hung up at #6 and I'm missing something basic in the structure of the stack. Has anyone managed to do this and have a sample solution to show how it's structured? I can create stacks all day long and add a IoC framework, but completely fail at getting it structured so that no concrete references are added to the UI layer. How else can the interface/concrete resolution of objects take place?
Surely some of you scholars have nipped this in the bud, please share some of this enlightenment with me :-)
ps - I've read Mark Seeman's book more than once.. I understand the concept of Composition Root... but have never seen one in use in an NTier solution and have been unable to implement the theory successfully
What I am looking for is a fleshed out solution stack of multiple projects that can be used as a base to start from. One that implements the composition root successfully and can be used to teach the SOLID principles by doing instead of telling. A solution that brings it all to life. See this question for reference.
My Shuttle Wiki FOSS has some elements of what you are after:
http://shuttlewiki.codeplex.com/
Although not every concern is in its own proejct/assembly I have found that it is not worth the effort to tease them apart unless you are really going to use the relevant assembly somewhere else. That being said, it is still very easy to split them out as care has been taken to keep the concerns decoupled.
Scanned through some of the comments. My opinion is that no project structure or technique should be used to try and prevent or protect other developers from using certain classes. Junior developers have to learn the ropes at some stage and some quick code walkthroughs would pick up coding not consistent with what you are trying to achieve.
Take a look at mine:
using repository pattern, ninject, entity framework 6, ...
https://github.com/mesuttalebi/NTierCSharpExample